How to use zfs send -R without risking union mounts?

John Nielsen lists at jnielsen.net
Wed Feb 19 04:22:56 UTC 2014


On Jan 16, 2014, at 12:54 PM, Darren Pilgrim <list_freebsd at bluerosetech.com> wrote:

> 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 at yesterday | zfs recv -F backup/tank
> zpool export backup
> 
> Then do incremental backups:
> 
> zpool import -N backup
> zfs send -R -I tank at yesterday tank at 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.

I've been working through this issue myself recently. My strategy is to always run "zfs receive" with '-u' so the received filesystems won't be mounted automatically, only use "zfs send -R" for the initial send", and thereafter change each dataset's "canmount" property to "off", a la
# zfs list -Ho name -r tank/backups/somehost | xargs -n 1 zfs set canmount=off

I'd love to find a better solution, but that's been adequate so far.

JN



More information about the freebsd-fs mailing list