Date: Sat, 2 Oct 2021 15:09:23 -0700 From: David Christensen <dpchrist@holgerdanske.com> To: freebsd-questions@freebsd.org Subject: Re: zfs q regarding backup strategy Message-ID: <69954781-9e3c-ba96-5f1e-9b4043ecf56c@holgerdanske.com> In-Reply-To: <20211002205504.9d81ee94caa231ee9b008d6a@sohara.org> 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> <20211002205504.9d81ee94caa231ee9b008d6a@sohara.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/2/21 12:55, Steve O'Hara-Smith wrote:
> 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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?69954781-9e3c-ba96-5f1e-9b4043ecf56c>