From owner-freebsd-questions@FreeBSD.ORG Wed Feb 19 04:22:56 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C40CA95; Wed, 19 Feb 2014 04:22:56 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 609901516; Wed, 19 Feb 2014 04:22:56 +0000 (UTC) Received: from [192.168.2.46] (c-50-160-123-105.hsd1.ut.comcast.net [50.160.123.105]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s1J4Maur050308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 23:22:37 -0500 (EST) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: How to use zfs send -R without risking union mounts? From: John Nielsen In-Reply-To: <52D83909.3080809@bluerosetech.com> Date: Tue, 18 Feb 2014 21:22:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52D83909.3080809@bluerosetech.com> To: Darren Pilgrim X-Mailer: Apple Mail (2.1827) X-DCC--Metrics: ns1.jnielsen.net 1282; Body=3 Fuz1=3 Fuz2=3 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-fs , freebsd-questions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 04:22:56 -0000 On Jan 16, 2014, at 12:54 PM, Darren Pilgrim = wrote: > When you send -R a filesystem, it very nicely retains all of the = properties. That also includes the mountpoint property. Setting = canmount=3Doff 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. >=20 > I want to create a backup using a process like: >=20 > Create the initial full backup: >=20 > zpool create backup /dev/gpt/backup > zfs create backup/tank > zfs send -R tank@yesterday | zfs recv -F backup/tank > zpool export backup >=20 > Then do incremental backups: >=20 > zpool import -N backup > zfs send -R -I tank@yesterday tank@today | zfs recv -F backup/tank > zpool export backup >=20 > 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: >=20 > mountpoint '/foo' exists and is not empty >=20 > 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. >=20 > 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=3Doff I'd love to find a better solution, but that's been adequate so far. JN