From owner-freebsd-fs@freebsd.org Mon Aug 13 09:47:20 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7774A106C736 for ; Mon, 13 Aug 2018 09:47:20 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu1176c.smtpx.saremail.com (cu1176c.smtpx.saremail.com [195.16.148.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D1C172601 for ; Mon, 13 Aug 2018 09:47:18 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.58] (unknown [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPA id ED2BD9DC65E; Mon, 13 Aug 2018 11:47:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: ZFS backup Q: send/recv and mountpoint property From: Borja Marcos In-Reply-To: Date: Mon, 13 Aug 2018 11:47:08 +0200 Cc: freebsd-fs@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dmitry Morozovsky X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 09:47:20 -0000 > On 22 Jul 2018, at 20:14, Dmitry Morozovsky wrote: >=20 >=20 > Problem:=20 >=20 > 0. on backup (zfs recv) server, I could not=20 > - overwrite mountpoint property (and I'd better avoid it) > - add canmount=3Doff, especially for child filesets, as it's not = inherited (which=20 > could be preferred behaviour) >=20 > 1. after backup server reboot, if special manual tweaks did not have = place,=20 > filesets from backup images overwrite backup filesets, render it = unuseable=20 >=20 > Any hints? >=20 > Or did I missed something trivial? Sorry about being late to the party. What I do is to receive the dataset using the -u option and after the = receive I set the canmount option to off. It would be great if zfs recv could set options = atomically when receiving a dataset, though. If you are doing incremental replications it=E2=80=99s always wise to = use canmount=3Doff and zfs recv -u. If you need to access files in the replicated dataset, = then clone a snapshot instead of mounting the dataset ifself.=20 Otherwise, unless you have atime=3Doff any read access will change the = last access timestamps, which means that incremental snapshots won=E2=80=99t apply = unless you force a rollback with a -N. Using -N is itself a bad idea because, in case of = error, you might end up rolling back something you don=E2=80=99t want. If you avoid the = rollback you will avoid making the recv destructive in any way. Actually, when replicating datasets I always add a hold to the last = replicated snaphsot so that I won=E2=80=99t delete them by mistake. I do something like this. - new snapshot (source@new) - hold source@new - Send incremental from @last @new | recv -u=20 - hold destination@new - set canmount=3Doff for destination@new - hold destination@new (would be nice to be able to add a hold = atomically as well) - release source@last, destination@last It would be awesome to have something like =E2=80=9Czfs recv -h = HOLD_NAME -o OPTION=3Dxxxx=E2=80=9D=20 Borja.