Date: Thu, 16 Jan 2014 11:54:49 -0800 From: Darren Pilgrim <list_freebsd@bluerosetech.com> To: freebsd-fs <freebsd-fs@freebsd.org>, freebsd-questions <freebsd-questions@freebsd.org> Subject: How to use zfs send -R without risking union mounts? Message-ID: <52D83909.3080809@bluerosetech.com>
next in thread | raw e-mail | index | archive | help
When you send -R a filesystem, it very nicely retains all of the properties. That also includes the mountpoint property. Setting canmount=off is the only safeguard against mounting a filesystem accidentally and it can't be inherited. That means it's rather dangerous to send -R the filesystems on which the OS reside. I want to create a backup using a process like: Create the initial full backup: zpool create backup /dev/gpt/backup zfs create backup/tank zfs send -R tank@yesterday | zfs recv -F backup/tank zpool export backup Then do incremental backups: zpool import -N backup zfs send -R -I tank@yesterday tank@today | zfs recv -F backup/tank zpool export backup The problem I ran into is zfs can mount the contents of backup/tank. Normally if you try to mount a ZFS filesystem at a non-empty directory, it gives the error: mountpoint '/foo' exists and is not empty During testing, I inadvertently dropped the -N flag to zpool import and ZFS successfully mounted everything on the backup drive over top of the live systems! I had two mounts for /, /var, /usr, /home, etc. Imagining the hell of that happening in production, with active filesystems, is an exercise for the reader. How do you force ZFS to never automatically mount a filesystem or any of its descendants? You can't recursively set properties and canmount can't be inherited, so I'm stuck on how to enforce this critical bit of safety.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52D83909.3080809>