zfs q regarding backup strategy

[David Christensen]

On 10/2/21 12:55, Steve O'Hara-Smith wrote:
> On Sat, 2 Oct 2021 11:23:30 -0700
> David Christensen <dpchrist at holgerdanske.com> wrote:
> 
>> 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 know exactly what you mean, trying to do this feels like trying to
> force the mechanism to do something it wasn't designed for. The only
> trouble I have with that is that I can't figure out what use case it was
> designed for.
> 
>> So, between zpool 'altroot', dataset 'canmount', and suitable scripting,
>> it might be possible to achieve your goal:
> 
> 	Yes likely, I have a design doc I tinker with occasionally trying
> to chart a path to perfection, altroot is neat but a pool for each archive
> is not nice that means lots of smallish vdevs for flexibility. Might not be
> too bad at that, easy to expand at least.


Assuming I can create a ZFS pool from one or more ZFS volume datasets 
(?), here is an idea:

1.  Create a large 'archive' pool.  Say, 10 TB.

2.  Within the archive pool, create many small volumes.  Say, 100 
volumes of 100 GB each.

3.  For each source, create a 'archive-source' pool using the 'zpool 
create -R' option and one or more volumes as required for capacity.

4.  From the archive server, replicate datasets from their respective 
source pools to their corresponding archive-source pools using the 'zfs 
receive -u' option.

5.  Upon receipt of a replica dataset, save the 'canmount' property (for 
restore).  If it is 'on', set it to 'notauto'.

6.  Upon receipt of a replica dataset, save the 'readonly' property (for 
restore).  If it is 'off', set it to 'on'.

7.  Mount or do not mount the replica datasets, as desired.

8.  On shutdown, export all archive-source pools.

9.  On boot, import all archive-source pools using the 'zpool import -R' 
option, and then mount or do not mount replica datasets.


The most obvious problem is if the system crashes between #4 and #5.  On 
subsequent boot, AIUI all previously active pools will be automatically 
imported (e.g. without 'altroot') and all datasets with 'canmount=on' 
will be mounted (according to 'mountpoint').  If two or more datasets 
are mounted at the same mount point, the results could be bad. 
'bootpool' and 'zroot' are likely cases.



The FreeBSD installer allows me to set the root pool name at install 
time, so I prepend the base hostname.  I use serialized names when 
creating data pools.  But I have not dared to rename boot pools, as I 
assume 'bootpool' is hard-coded into the bootloader chain (?).


Can the boot pool ('bootpool') be renamed on FreeBSD?


David