ZFS Send / Receive Recursively Without Properties

Karli Sjöberg karli.sjoberg at slu.se
Mon Jan 5 19:40:14 UTC 2015


Den 5 jan 2015 20:06 skrev Tim Gustafson <tjg at ucsc.edu>:
>
> Hi,
>
> We're using ZFS send/receive to maintain off-site snapshots of system
> "A" onto system "B" for redundancy.  The data on system "B" is
> read-only, and would only ever be used to transfer data back to system
> "A" in the event of a hardware failure.
>
> We're currently this command to achieve this:
>
> /sbin/zfs send -R -I 'tank/root at 2015-01-04' 'tank/root at 2015-01-05' |
> /usr/bin/ssh -i /root/.ssh/id_rsa 'user at backup-server'
> /usr/local/bin/sudo /sbin/zfs receive -v -F -u -n
> 'tank/notbackedup/source-server/root'
>
> This works well, except that it sets the mountpoints on server "B"
> server's copy of the file systems to whatever they were on the source
> system, which overwrites server "B"'s root file system when we send
> the root file system from server "A".
>
> If I drop the -R parameter to ZFS send, then it does not overwrite the
> mountpoints, but it also does not destroy the non-existent snapshots
> on the server "B".  Snapshots on server "A" are automatically
> destroyed by a script after 7 days, and we don't want to accumulate
> snapshots on server "B" that have been destroyed from server "A".  We
> also would prefer to not run a snapshot purging script on server "B"
> because ultimately this solution will be used for multiple source
> servers, and each of them have different snapshot retention policies
> that I'd like to not have to maintain in two separate places.
>
> Is there any way to recursively send (and destroy) snapshots on the
> server "B" without also copying the mountpoint property?

Can't say much for the other stuff but if you don't want the filesystems to mount, set 'canmount=noauto'. But you'll have to set all the filesystems you want mounted at boot in '/etc/fstab' then.

We have our own script that takes a new snap, sends it over, removes the base snapshot, then renames the new snapshot to base. This to only update the data on secondary server. We then use another snapshot management tool to take scheduled snapshots with different retentions as a complement to that.

/K

>
> --
>
> Tim Gustafson
> tjg at ucsc.edu
> 831-459-5354
> Baskin Engineering, Room 313A
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"


More information about the freebsd-fs mailing list