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>
index | next in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52D83909.3080809>