Trick to working with local backups using zfs send

Posted:
Sat Sep 16, 2017 9:42 am
by jojo45
I am backing up my local pool to another local hard drive using:
zfs send -R tank1@snap | zfs receive -F tank2
Both tank1 and tank2 are local and attached to the Mac.
The system gets confused. There are two files systems with the same name now and writes sometimes go to one pool and sometimes to the other.
Are there any best practices to prevent this from happening and working with local backups?
Re: Trick to working with local backups using zfs send

Posted:
Sun Sep 17, 2017 1:39 am
by lundman
Can't you just give it a unique name on receive? zfs recv tank2/backupoftank1
Re: Trick to working with local backups using zfs send

Posted:
Sun Sep 17, 2017 5:32 am
by Jimbo
Don't mount the target pool/volume/whatever (i.e. zpool import -N <target_pool_here>) this will not mount the file systems in the pool and thus the OS will not care (well, won't see actually) any "duplicate" file systems that it could write to. The file systems on the target pool do not need to be mounted for a recieve and its often cleaner not to mount the file systems anyway (no Spotlight, no OS or application confusion).
The one here is ZVOls. I'f you've send/recieving a snap including a ZOL, import -N will not stop the ZVOL being mounted by the OS once it sees the block device (thanks macOS!), so when you import your target pool - which by extension will have a ZVOL on it, if not now, when the first recieve completes it will - macOS will mount it in Finder. Eject this volume before starting your send/recieve.
I have a timemachine ZVOL that is used by a number of remote machines and I periodically back it up (my ZVOL based time machine backups) to another external drive attached locally via send recieve. Works fine with import -N and eject of the I-don't-care-will-mount-automatically-anyway ZVOL from my backup-backup pool, then running then send/recieve.
Hope that helps.
Re: Trick to working with local backups using zfs send

Posted:
Sun Sep 17, 2017 6:08 am
by jojo45
Many thanks, Jimbo. Your solution took care of the problem.