Is a dataset required for zfs replication?

[Chris Hager]

First off. Thankyou to all the freenas gods that moderate this forum. I've usually found a thread with the same problems I've encountered and have had an amazing experience even just lurking this forum.

My (small) issue. I have several Dell R510's configured with 4TB SATA drives. Currently they are doing zfs replication to identical boxes. This has worked flawlessly and for the most part would work well in case of hardware failure or user error. The one issue I have is that the configuration I've setup requires a dataset to exist under a volume on the backup side. The primary boxes would be /med05/med05. The backup boxes are /backup/backup/med05. See below:

My goal would be to have /backup/med05 instead of having an extra layer. While this is a small problem it changes the address users connect to if they ever had to use the backup machine as a primary. They currently connect using "nfs://med05/mnt/med05" if they had to change it it would be "nfs://med05/mnt/backup/med05." This isn't a problem 99.99% of the time. However in a disaster scenario this would be somewhat frustrating for people who connect to these on a daily basis.


Hardware configuration:
12 4TB drives in RaidZ2
2 Intel S3700 SSD's for cache/log
64GB Ram
Dual X5650 processors
Intel 10G X520-DA2 NIC

 

[depasseg]

There are 2 issues going on here:

1. There are always 2 levels of the same name (whether backup/backup or med05/med05). That's just the way FreeNAS sets up the volumes/pools/datasets
2. You are likely replicating your medo5 dataset to backup/med05. Instead, you should back it up to backup (of course this prevents you from replicating anything else to backup). [If you ever needed to do a quick name change, you could do the following on "backup": 1) use GUI to detach backup 2) use CLI "zfs attach back med05" (this renames it) 3) zfs detach med05 4)use GUI to import med05]

 

[danb35]

There are always 2 levels of the same name (whether backup/backup or med05/med05). That's just the way FreeNAS sets up the volumes/pools/datasets

More precisely, it's a ZFS thing. There is always a dataset created with the same name as the pool.

 

[depasseg]

Good point. I meant the visual representation (the screenshots) was FreeNAS. And it doesn't have anything to do with the actual mounted file system path.

 

[Chris Hager]

Thank you for the reply. I'm fine with the first dataset being named after the pool. I shouldn't have wrote /backup/med05 since that wouldn't exist. However when I point a replication task at just "backup" it fails and says there is no dataset to copy to (I don't have the exact error in front of me). When I create the med05 dataset under backup and point the zfs replication to backup/med05 it works just fine.

I do identical clones so no other boxes would ever need to replicate to the same location.

 

[depasseg]

Post the actual error, it could help. I'm wondering if it's a snapshot issue, or a replication setup issue.

I'm doing exactly (I think) what you are trying to do. TANK is being replicated locally to BACKUP-TANK as well as to BACKUP-TANK2 on another server (172.16.1.82).

 

[Chris Hager]

Yup thats exactly what I'm trying to do. So now I'm assuming I have something slightly misconfigured.

Below is the error I get when I have it setup to replicate to the dataset on the destination. In this case med06 is the destination volume/dataset. The second picture includes a "backup" dataset. When I take the existing failing replication configuration and use med06/backup as the destination it will start replicating successfully.

*Edit to add attachment.

 

[depasseg]

Have you looked at the backup server dataset to see what is there? Replication, sometimes while working properly, sometimes reports a false failure. That generic failure message doesn't mean a lot.

 

[Chris Hager]

Nothing gets transferred. Network utilization never goes above minimal and used disk space doesn't change on the destination.

This is on 9.3.1 FWIW.

 

[depasseg]

I would destroy med06, recreate it, and then see if the replication works. There used to be an initialization option, but that was recently removed, and supposedly made automatic. I wonder if the fact that the destination isn't empty is causing the problem.