Date: Sat, 2 Oct 2021 20:55:04 +0100 From: Steve O'Hara-Smith <steve@sohara.org> To: David Christensen <dpchrist@holgerdanske.com> Cc: freebsd-questions@freebsd.org Subject: Re: zfs q regarding backup strategy Message-ID: <20211002205504.9d81ee94caa231ee9b008d6a@sohara.org> In-Reply-To: <daf9ba49-82a3-670c-f59c-745e0c315f18@holgerdanske.com> References: <YVZM1HnPuwIUQpah@ceres.zyxst.net> <ba54a415-da45-e662-73fe-65702c4131e2@holgerdanske.com> <YVcXsF5NFq2abE%2B7@ceres.zyxst.net> <20211001222816.a36e9acbd4e8829aed3afb68@sohara.org> <809e4f3b-9e59-eb53-5b7d-0bcf7e401cd5@holgerdanske.com> <20211002115440.85c4342a49fe6e4573c37dd0@sohara.org> <daf9ba49-82a3-670c-f59c-745e0c315f18@holgerdanske.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2 Oct 2021 11:23:30 -0700 David Christensen <dpchrist@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@sohara.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20211002205504.9d81ee94caa231ee9b008d6a>