zfs q regarding backup strategy

[Steve O'Hara-Smith]

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.

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