From owner-freebsd-fs@FreeBSD.ORG  Thu Jan 16 19:54:46 2014
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 8A8A79B4;
 Thu, 16 Jan 2014 19:54:46 +0000 (UTC)
Received: from luigi.brtsvcs.net (luigi.brtsvcs.net
 [IPv6:2607:fc50:1000:1f00::2])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id 5EDE612DB;
 Thu, 16 Jan 2014 19:54:46 +0000 (UTC)
Received: from chombo.houseloki.net (c-71-236-222-167.hsd1.wa.comcast.net
 [71.236.222.167])
 by luigi.brtsvcs.net (Postfix) with ESMTPSA id 655722D4FAE;
 Thu, 16 Jan 2014 11:54:44 -0800 (PST)
Received: from [IPv6:2601:7:880:bd0:c59a:a6c:f5b:2771] (unknown
 [IPv6:2601:7:880:bd0:c59a:a6c:f5b:2771])
 by chombo.houseloki.net (Postfix) with ESMTPSA id 3B7EC280;
 Thu, 16 Jan 2014 11:54:42 -0800 (PST)
Message-ID: <52D83909.3080809@bluerosetech.com>
Date: Thu, 16 Jan 2014 11:54:49 -0800
From: Darren Pilgrim <list_freebsd@bluerosetech.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: freebsd-fs <freebsd-fs@freebsd.org>, 
 freebsd-questions <freebsd-questions@freebsd.org>
Subject: How to use zfs send -R without risking union mounts?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs/>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 19:54:46 -0000

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.