ZFS full system backup hoses the backup host.

[Allan Jude]

On 2016-02-26 05:26, Jan Bramkamp wrote:
> 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 at 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?
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"

With zxfer this does not happen, because it creates the empty dataset,
then manually copies the permissions.

-- 
Allan Jude

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20160226/a9f341c7/attachment.sig>