zfs q regarding backup strategy

[David Christensen]

On 10/2/21 03:54, Steve O'Hara-Smith wrote:
> On Fri, 1 Oct 2021 16:10:44 -0700 David Christensen wrote:
>> On 10/1/21 14:28, Steve O'Hara-Smith wrote:

>>> Also there is the
>>> irritating detail that one of the properties of a ZFS filesystem is its
>>> mount point and while you can run zfs recv in such a way as not to mount
>>> the received filesystems 


I failed to respond to that on my previous reply.


Yes -- 'zfs receive' and the '-u' option.  I'm not using it now, but can 
see its usefulness.


>>> they will get mounted on reboot which makes
>>> backing up several root filesystems to an archive server a little
>>> tricky!
>>
>>
>> Are you referring to the zpool(8) property 'altroot'?
> 
> 	If only it were a persistent property it would be more useful and
> if it were available at filesystem level.


I have found that ZFS is very carefully engineered, and that any issues 
I encounter are invariably PEBKAC.  So, there must be compelling reasons 
why 'altroot' is a pool property and why 'altroot' is not persistent. 
Similar, the absence of property manipulation options for the 'zfs send' 
and 'zfs receive' commands.


>> I recall that FreeNAS uses altroot, and it is persistent across reboots.
> 
> 	Oh now that's a neat trick.
> 
>>    I wonder how they accomplished that?  Import scripts on boot and
>> export scripts on shutdown?  But, how to deal with an unclean shutdown
>> and/or failed export?  STFW I do not see any clues.
> 
> 	Thinking about it I'd guess they register the altroot in some
> database (append to a text file perhaps) at the time they set it on
> receiving the initial stream for the filesystem and creating the
> filesystem, then as you say use a boot time script to restore the altroot
> settings.
> 
> 	I wonder if the FreeNAS solution is available for use, I only see
> some python libraries in the ports.
> 
>> Perhaps a top-level "archive" pool, one ZFS volume per <source>, one
>> pool per volume, and some work-around to achieve persistent altroot's (?).
> 
> 	A separate pool for each archive ? I don't like that pools are
> rather inflexible things, I rather want to share that stack of big disks.


RTFM/STFW some more, I discovered the dataset 'canmount' property:

     When the noauto value is set, a dataset can only be mounted and
     unmounted explicitly. The dataset is not mounted automatically when
     the dataset is created or imported, nor is it mounted by the "zfs
     mount -a" command or unmounted by the "zfs umount -a" command.


So, between zpool 'altroot', dataset 'canmount', and suitable scripting, 
it might be possible to achieve your goal:


 >>> What I really want is a [rock] solid reliable archive server with
 >>> all the hierarchies archived mounted read only under something
 >>> like/archive/<source>/.


David