zfs q regarding backup strategy

[Steve O'Hara-Smith]

On Sat, 2 Oct 2021 15:09:23 -0700
David Christensen <dpchrist at holgerdanske.com> wrote:

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

	I don't think you can create a pool on top of zvols, I couldn't get
it to work last time I tried.

> 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.

	Why not just split the drives into 100GB partitions with gpart
rather than attempting to nest zpools ?

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

	Also record the root mount for use at boot time.

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

	Once you have altroot working then you want the dataset mounted -
read only though.

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

	No need.

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

	Yes.

	It is also necessary to check to see whether the target pool has
enough space and if not throw a few more logs on the fire.

> 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.

	This is where the boot script to restore the altroot settings comes
in - but it has to run before zfs attempts the mounts.

-- 
Steve O'Hara-Smith <steve at sohara.org>