Date: Mon, 13 Aug 2018 11:47:08 +0200 From: Borja Marcos <borjam@sarenet.es> To: Dmitry Morozovsky <marck@rinet.ru> Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS backup Q: send/recv and mountpoint property Message-ID: <BE8539E1-351B-4C77-8A34-FE6CE665AA40@sarenet.es> In-Reply-To: <alpine.BSF.2.00.1807222110450.28320@woozle.rinet.ru> References: <alpine.BSF.2.00.1807222110450.28320@woozle.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 22 Jul 2018, at 20:14, Dmitry Morozovsky <marck@rinet.ru> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BE8539E1-351B-4C77-8A34-FE6CE665AA40>