Date: Fri, 26 Feb 2016 11:26:22 +0100 From: Jan Bramkamp <crest@rlwinm.de> To: freebsd-hackers@freebsd.org Subject: Re: ZFS full system backup hoses the backup host. Message-ID: <56D0284E.3010808@rlwinm.de> In-Reply-To: <56CF6FB0.1010001@freebsd.org> References: <CACpH0Me58jK%2BOz3PCqH93NEn=5V1SKwPGdku62sAVLVh%2BWxEeA@mail.gmail.com> <56CF6FB0.1010001@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25/02/16 22:18, Allan Jude wrote: > On 2016-02-25 15:58, Zaphod Beeblebrox wrote: >> This violated POLA for me. I backed up a host using: >> >> time zfs send -vRI @backup-1-e zroot@backup-1-f | ssh backuphost "zfs >> receive -vFud zroot/backup/host" >> >> >> Only to find that the backup host (a week later) failed to reboot? The >> problem? Well... -u on receive marks the filesystem as unmounted only >> "right now" not "next reboot" and -R on send implies -p (send dataset >> attributes) and... >> >> ... zroot/ROOT/default mountpoint=/ (among others). >> >> The only hackish way to fix this I see is to have a list of mountpoints to >> correct --- which is partially what I'm trying to avoid by using -R --- I >> just want the whole thing backed up. >> >> What have other people done to get around this and/or can we either put in >> an "ignore properties" on receive flag or a -R on send that doesn't send >> them? > > The sysutils/zxfer script allows you to override properties during > replication, so I usually set readonly=on and for such a backup would > set mountpoint=none Do you know if this is race free or is there a moment on the receiving system where it has an (unmounted) dataset with mountpoint=/ which would break the system (possibly in interesting ways) after a crash?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56D0284E.3010808>