Date: Sat, 2 Oct 2021 11:23:30 -0700 From: David Christensen <dpchrist@holgerdanske.com> To: freebsd-questions@freebsd.org Subject: Re: zfs q regarding backup strategy Message-ID: <daf9ba49-82a3-670c-f59c-745e0c315f18@holgerdanske.com> In-Reply-To: <20211002115440.85c4342a49fe6e4573c37dd0@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/2/21 03:54, Steve O'Hara-Smith wrote:
> On Fri, 1 Oct 2021 16:10:44 -0700 David Christensen wrote:
>> On 10/1/21 14:28, Steve O'Hara-Smith wrote:
>>> Also there is the
>>> irritating detail that one of the properties of a ZFS filesystem is its
>>> mount point and while you can run zfs recv in such a way as not to mount
>>> the received filesystems
I failed to respond to that on my previous reply.
Yes -- 'zfs receive' and the '-u' option. I'm not using it now, but can
see its usefulness.
>>> they will get mounted on reboot which makes
>>> backing up several root filesystems to an archive server a little
>>> tricky!
>>
>>
>> Are you referring to the zpool(8) property 'altroot'?
>
> If only it were a persistent property it would be more useful and
> if it were available at filesystem level.
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 recall that FreeNAS uses altroot, and it is persistent across reboots.
>
> Oh now that's a neat trick.
>
>> I wonder how they accomplished that? Import scripts on boot and
>> export scripts on shutdown? But, how to deal with an unclean shutdown
>> and/or failed export? STFW I do not see any clues.
>
> Thinking about it I'd guess they register the altroot in some
> database (append to a text file perhaps) at the time they set it on
> receiving the initial stream for the filesystem and creating the
> filesystem, then as you say use a boot time script to restore the altroot
> settings.
>
> I wonder if the FreeNAS solution is available for use, I only see
> some python libraries in the ports.
>
>> Perhaps a top-level "archive" pool, one ZFS volume per <source>, one
>> pool per volume, and some work-around to achieve persistent altroot's (?).
>
> A separate pool for each archive ? I don't like that pools are
> rather inflexible things, I rather want to share that stack of big disks.
RTFM/STFW some more, I discovered the dataset 'canmount' property:
When the noauto value is set, a dataset can only be mounted and
unmounted explicitly. The dataset is not mounted automatically when
the dataset is created or imported, nor is it mounted by the "zfs
mount -a" command or unmounted by the "zfs umount -a" command.
So, between zpool 'altroot', dataset 'canmount', and suitable scripting,
it might be possible to achieve your goal:
>>> What I really want is a [rock] solid reliable archive server with
>>> all the hierarchies archived mounted read only under something
>>> like/archive/<source>/.
David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?daf9ba49-82a3-670c-f59c-745e0c315f18>