ZFS backup Q: send/recv and mountpoint property

[Borja Marcos]

> On 22 Jul 2018, at 20:14, Dmitry Morozovsky <marck at rinet.ru> wrote:
> 
> 
> Problem: 
> 
> 0. on backup (zfs recv) server, I could not 
> - overwrite mountpoint property (and I'd better avoid it)
> - add canmount=off, especially for child filesets, as it's not inherited (which 
> could be preferred behaviour)
> 
> 1. after backup server reboot, if special manual tweaks did not have place, 
> filesets from backup images overwrite backup filesets, render it unuseable 
> 
> Any hints?
> 
> 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’s always wise to use canmount=off
and zfs recv -u. If you need to access files in the replicated dataset, then clone
a snapshot instead of mounting the dataset ifself. 

Otherwise, unless you have atime=off any read access will change the last access
timestamps, which means that incremental snapshots won’t 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’t 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’t delete them by mistake.

I do something like this.

- new snapshot (source at new)

- hold  source at new

- Send incremental from @last @new | recv -u 

- hold destination at new

- set canmount=off for destination at new

- hold destination at new (would be nice to be able to add a hold atomically as well)

- release source at last, destination at last



It would be awesome to have something like “zfs recv -h HOLD_NAME -o OPTION=xxxx” 





Borja.