Replication settings in Manual

[adrianwi]

The manual gives an example of how to configure replication settings

Code:

•192.168.2.2 will be referred to as PUSH. This system has a periodic snapshot task for the ZFS dataset /mnt/local/data.
•192.168.2.6 will be referred to as PULL. This system has an existing ZFS volume named /mnt/remote which will store the pushed snapshots.

It then goes onto describe how to set-up the Replication Task, with the first two fields completed with

Code:

•the Volume/Dataset is local/data
•the Remote ZFS Volume/Dataset is remote

Using these settings would you expect the data contained within /mnt/local/data to appear in

a) /mnt/remote
b) /mnt/remote/data
c) other

Thanks

 

[rogerh]

The manual gives an example of how to configure replication settings

Code:

•192.168.2.2 will be referred to as PUSH. This system has a periodic snapshot task for the ZFS dataset /mnt/local/data.
•192.168.2.6 will be referred to as PULL. This system has an existing ZFS volume named /mnt/remote which will store the pushed snapshots.

It then goes onto describe how to set-up the Replication Task, with the first two fields completed with

Code:

•the Volume/Dataset is local/data
•the Remote ZFS Volume/Dataset is remote

Using these settings would you expect the data contained within /mnt/local/data to appear in

a) /mnt/remote
b) /mnt/remote/data
c) other

Thanks

Prior to 9.3.1, definitely b), and it will make the dataset 'data' for you. From 9.3.1 then all bets are off, there seem to be some problems.


However, I would strongly suggest setting up a new dataset on PULL to put the backup in. Eg new dataset 'remote/backupplace', which will be mounted at /mnt/remote/backupplace. Then if you set the Remote ZFS Volume/Dataset as 'remote/backupplace' the replicand will turn up in '/mnt/remote/backupplace/data'.

The reason I say that is that it all seems to just work better that way, and it doesn't seem to be just due to previous problems with the .system dataset. I have no proof!