btrfs recommended layout for snapshots?

btrfs recommended layout for snapshots?

[Nicolas Graves via Development of GNU Guix and the GNU System distribution.]

Hi! I've installed a guix system with btrfs for some time, but I now
want to configure it to properly handle snapshots, and there doesn't
seem to be a lot of resources about the way to do it properly.

What I mean is that by having a simple /root/boot/home/store/log layout
doesn't seem to really be adapted to snapshotting regurlarly. The most
comprehensive documentation I've found yet about how to do it properly
is here :
https://documentation.suse.com/sles/12-SP4/html/SLES-all/cha-snapper.html#snapper-dir-excludes

It explains quite clearly why some subvolumes are better be left alone /
not snapshotted. Although this is quite clear, I'm wondering about the
implications for a guix system, where basically most of what would be
useful to store in a btrfs snapshot is already handled by guix.

I guess there are two ways to consider the issue :
- either going for a simple layout with / snapshots, with a snapshot
of the store and exclusion of the directories listed in the previous
link. But that would mean we are regularly snapshotting the store, which
is not really useful if we suppose that we can get back what we need
with a system / home reconfigure.

- either not snapshotting the rootfs / at all, with the hypothesis that
  we get it back entirely from config files. Is that possible ? Is there
  information in / (I think of /etc in particular) that is saved, not
  temporary and not managed by guix system that would justify that we
  want to snapshot / at all?
  This would allow to simply care about only a few "user data"
  directories, and be sure to not miss anything when there's a need to
  restore the state.

I can't find easily a case of successful use of the second
configuration, but would be glad to find one, as well as some discussion
about what would be a recommended way to secure the state beyond
dotfiles. 

-- 
Best regards,
Nicolas Graves

Re: btrfs recommended layout for snapshots?

[Nicolas Graves via Development of GNU Guix and the GNU System distribution.]

> - either not snapshotting the rootfs / at all, with the hypothesis that
>   we get it back entirely from config files. Is that possible ? Is there
>   information in / (I think of /etc in particular) that is saved, not
>   temporary and not managed by guix system that would justify that we
>   want to snapshot / at all?
>   This would allow to simply care about only a few "user data"
>   directories, and be sure to not miss anything when there's a need to
>   restore the state.
>
> I can't find easily a case of successful use of the second
> configuration, but would be glad to find one, as well as some discussion
> about what would be a recommended way to secure the state beyond
> dotfiles.

I've found some equivalent information on the NixOS side here :
https://nixos.wiki/wiki/Impermanence

Some (rare) directories indeed seem that would better be saved because
their information is useful for the system, in the case of NixOS, it
seems to be "/etc/nixos", "/etc/NetworkManager" (for system
connections), "/var/log", "/var/lib".

However, I have much more files that aren't linked in the store,
especially in the /etc directory (at least 20 files). 

Has anybody tried to do something like this on Guix?
    
-- 
Best regards,
Nicolas Graves

Re: btrfs recommended layout for snapshots?

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2422 bytes --]

On Mon, Aug 14, 2023 at 04:41:52PM +0200, Nicolas Graves via Development of GNU Guix and the GNU System distribution. wrote:
> 
> > - either not snapshotting the rootfs / at all, with the hypothesis that
> >   we get it back entirely from config files. Is that possible ? Is there
> >   information in / (I think of /etc in particular) that is saved, not
> >   temporary and not managed by guix system that would justify that we
> >   want to snapshot / at all?
> >   This would allow to simply care about only a few "user data"
> >   directories, and be sure to not miss anything when there's a need to
> >   restore the state.
> >
> > I can't find easily a case of successful use of the second
> > configuration, but would be glad to find one, as well as some discussion
> > about what would be a recommended way to secure the state beyond
> > dotfiles.
> 
> I've found some equivalent information on the NixOS side here :
> https://nixos.wiki/wiki/Impermanence
> 
> Some (rare) directories indeed seem that would better be saved because
> their information is useful for the system, in the case of NixOS, it
> seems to be "/etc/nixos", "/etc/NetworkManager" (for system
> connections), "/var/log", "/var/lib".
> 
> However, I have much more files that aren't linked in the store,
> especially in the /etc directory (at least 20 files). 
> 
> Has anybody tried to do something like this on Guix?

I'm still not using most of the features of btrfs, just compression.

Inside /etc/guix /etc/guix/acl is managed with the guix-service-type.
IMO the signing keys should be rotated if you reload a machine (or at
least properly securing them is more effort than is worthwhile), and
/etc/guix/machines.scm isn't secret. I can't think of anything else in
/etc I'd want besides /etc/guix/machines.scm.

With that in mind, the only thing I could see snapshotting is /home, and
living with the knowledge that I might have to adjust or remove some
symlinks when rolling back. As far as what inside /home/<user> is worth
backing up and what isn't, I suppose that depends on their use of
guix-home or if they want to save space by not backing up ~/.cache or
~/.var or the like.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: btrfs recommended layout for snapshots?

[Maxim Cournoyer]

Hi Efraim and others,

Efraim Flashner <efraim@flashner.co.il> writes:

> On Mon, Aug 14, 2023 at 04:41:52PM +0200, Nicolas Graves via
> Development of GNU Guix and the GNU System distribution. wrote:
>> 
>> > - either not snapshotting the rootfs / at all, with the hypothesis that
>> >   we get it back entirely from config files. Is that possible ? Is there
>> >   information in / (I think of /etc in particular) that is saved, not
>> >   temporary and not managed by guix system that would justify that we
>> >   want to snapshot / at all?
>> >   This would allow to simply care about only a few "user data"
>> >   directories, and be sure to not miss anything when there's a need to
>> >   restore the state.
>> >
>> > I can't find easily a case of successful use of the second
>> > configuration, but would be glad to find one, as well as some discussion
>> > about what would be a recommended way to secure the state beyond
>> > dotfiles.
>> 
>> I've found some equivalent information on the NixOS side here :
>> https://nixos.wiki/wiki/Impermanence
>> 
>> Some (rare) directories indeed seem that would better be saved because
>> their information is useful for the system, in the case of NixOS, it
>> seems to be "/etc/nixos", "/etc/NetworkManager" (for system
>> connections), "/var/log", "/var/lib".
>> 
>> However, I have much more files that aren't linked in the store,
>> especially in the /etc directory (at least 20 files). 
>> 
>> Has anybody tried to do something like this on Guix?
>
> I'm still not using most of the features of btrfs, just compression.

Some side topic, but an easy and useful way to leverage Btrfs snapshots
is through 'btrbk', for automatic and incremental backups.  I have mind
setup via this mcron job that fires ever hour:

--8<---------------cut here---------------start------------->8---
(define btrbk-job
  #~(job '(next-hour)
         (lambda ()
           (system* #$(file-append btrbk "/bin/btrbk")
                    "-q" "-c" #$(local-file "btrbk.conf") "run"))
         "btrbk"))
--8<---------------cut here---------------end--------------->8---

and this special extra file service:

--8<---------------cut here---------------start------------->8---
(extra-special-file "/etc/btrbk.conf" (local-file "btrbk.conf"))
--8<---------------cut here---------------end--------------->8---

that reads like:

--8<---------------cut here---------------start------------->8---
lockfile                   /var/lock/btrbk.lock
transaction_log            /var/log/btrbk.log
snapshot_dir               _btrbk_snap
stream_buffer              256m

snapshot_preserve_min   2d
snapshot_preserve       14d

target_preserve_min     no
target_preserve         20d 10w 6m

archive_preserve_min    latest
archive_preserve        12m 7y

# TODO: /etc/crypttab with automatic mounting of external drives
target /media/maxim/btr_backup/_btrbk

# TODO: Backup @root?
volume                     /mnt/btr_pool
  subvolume @home
  subvolume @data
--8<---------------cut here---------------end--------------->8---

It'd be nice to add a btrbk-service-type some day to make this easier
for people to get started.

-- 
Thanks,
Maxim

Re: btrfs recommended layout for snapshots?

[Nicolas Graves via Development of GNU Guix and the GNU System distribution.]

On 2023-08-14 16:41, Nicolas Graves wrote:

>> - either not snapshotting the rootfs / at all, with the hypothesis that
>>   we get it back entirely from config files. Is that possible ? Is there
>>   information in / (I think of /etc in particular) that is saved, not
>>   temporary and not managed by guix system that would justify that we
>>   want to snapshot / at all?
>>   This would allow to simply care about only a few "user data"
>>   directories, and be sure to not miss anything when there's a need to
>>   restore the state.
>>
>> I can't find easily a case of successful use of the second
>> configuration, but would be glad to find one, as well as some discussion
>> about what would be a recommended way to secure the state beyond
>> dotfiles.
>
> I've found some equivalent information on the NixOS side here :
> https://nixos.wiki/wiki/Impermanence
>
> Some (rare) directories indeed seem that would better be saved because
> their information is useful for the system, in the case of NixOS, it
> seems to be "/etc/nixos", "/etc/NetworkManager" (for system
> connections), "/var/log", "/var/lib".

Thank you all for your answers!

I actually managed to replicate the impermanence functionality by
creating btrfs subvolumes for "/etc/guix" "/etc/NetworkManager"
"/var/log" "/var/lib" "/var/guix" and 4 light patches (I'm currently
trying to remove one I think might be not necessary, will send them
here. They basically amount to create directories when they might not be
present or allowing the root "none" to pass to the mount call).

This allows me to start with a tmpfs rootfs, and the only annoying thing
I experience not is that the root password is not set (the account
password is set though, since we can include that in the definition of
an os). Boot time is a bit higher since /etc/machine-id and some other
files have to be recreated, but that's not really noticeable.

I don't know if I'll stick to this "impermanent" mode, but at least this
gives me the right information about what directories are worth
considering for snapshots (doesn't mean they are worth snapshotting),
and what a "precise" btrfs layout on Guix would have to consider.

I guess it's possible to do the same with my home as well (thus only
saving actual data and not consecutive linking metadata), but that might
require some more time and fine-grained applications considerations.

@Efraim : I don't have a /etc/guix/machines.scm to save (I don't have an
offloading deamon set for now), IIUC this means I could be doing as good
without "/etc/guix". What are the signing keys used for?

One weakness from this impermanence feature is that it's actually
application-dependent. For guix-system it's not very damaging (except if
we want very low-level optimizations, like setting nodatacow on
subvolumes with databases etc), but for guix-home, it makes things much
more difficult. @Andrew Tropin : maybe that's something we could in RDE in
a state-btrfs in (gnu home-services state) if we find a way to migrate
directories to subvolumes safely and reproducibly.

-- 
Best regards,
Nicolas Graves

Re: btrfs recommended layout for snapshots?

[Nicolas Graves via Development of GNU Guix and the GNU System distribution.]

> I actually managed to replicate the impermanence functionality by
> creating btrfs subvolumes for "/etc/guix" "/etc/NetworkManager"
> "/var/log" "/var/lib" "/var/guix" and 4 light patches (I'm currently
> trying to remove one I think might be not necessary, will send them
> here. They basically amount to create directories when they might not be
> present or allowing the root "none" to pass to the mount call).

Patches are available on bug#65335. 
-- 
Best regards,
Nicolas Graves

Re: btrfs recommended layout for snapshots?

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 3938 bytes --]

On Wed, Aug 16, 2023 at 10:10:25AM +0200, Nicolas Graves wrote:
> On 2023-08-14 16:41, Nicolas Graves wrote:
> 
> >> - either not snapshotting the rootfs / at all, with the hypothesis that
> >>   we get it back entirely from config files. Is that possible ? Is there
> >>   information in / (I think of /etc in particular) that is saved, not
> >>   temporary and not managed by guix system that would justify that we
> >>   want to snapshot / at all?
> >>   This would allow to simply care about only a few "user data"
> >>   directories, and be sure to not miss anything when there's a need to
> >>   restore the state.
> >>
> >> I can't find easily a case of successful use of the second
> >> configuration, but would be glad to find one, as well as some discussion
> >> about what would be a recommended way to secure the state beyond
> >> dotfiles.
> >
> > I've found some equivalent information on the NixOS side here :
> > https://nixos.wiki/wiki/Impermanence
> >
> > Some (rare) directories indeed seem that would better be saved because
> > their information is useful for the system, in the case of NixOS, it
> > seems to be "/etc/nixos", "/etc/NetworkManager" (for system
> > connections), "/var/log", "/var/lib".
> 
> Thank you all for your answers!
> 
> I actually managed to replicate the impermanence functionality by
> creating btrfs subvolumes for "/etc/guix" "/etc/NetworkManager"
> "/var/log" "/var/lib" "/var/guix" and 4 light patches (I'm currently
> trying to remove one I think might be not necessary, will send them
> here. They basically amount to create directories when they might not be
> present or allowing the root "none" to pass to the mount call).

With impermanence I'd save /etc/ssh so you don't have to regenerate keys
each time. Or perhaps look into SSH Certificate Authority if you want to
go crazy with it.

> This allows me to start with a tmpfs rootfs, and the only annoying thing
> I experience not is that the root password is not set (the account
> password is set though, since we can include that in the definition of
> an os). Boot time is a bit higher since /etc/machine-id and some other
> files have to be recreated, but that's not really noticeable.
> 
> I don't know if I'll stick to this "impermanent" mode, but at least this
> gives me the right information about what directories are worth
> considering for snapshots (doesn't mean they are worth snapshotting),
> and what a "precise" btrfs layout on Guix would have to consider.
> 
> I guess it's possible to do the same with my home as well (thus only
> saving actual data and not consecutive linking metadata), but that might
> require some more time and fine-grained applications considerations.
> 
> @Efraim : I don't have a /etc/guix/machines.scm to save (I don't have an
> offloading deamon set for now), IIUC this means I could be doing as good
> without "/etc/guix". What are the signing keys used for?

The signing keys are used when offloading derivations to other machines.
There's an example usage, with saving them for later, in the
hurd-vm-service-type and the secret-root (by default in /etc/childhurd).

> One weakness from this impermanence feature is that it's actually
> application-dependent. For guix-system it's not very damaging (except if
> we want very low-level optimizations, like setting nodatacow on
> subvolumes with databases etc), but for guix-home, it makes things much
> more difficult. @Andrew Tropin : maybe that's something we could in RDE in
> a state-btrfs in (gnu home-services state) if we find a way to migrate
> directories to subvolumes safely and reproducibly.
> 
> -- 
> Best regards,
> Nicolas Graves

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: btrfs recommended layout for snapshots?

[Nicolas Graves via Development of GNU Guix and the GNU System distribution.]

On 2023-08-16 10:10, Nicolas Graves wrote:

> I guess it's possible to do the same with my home as well (thus only
> saving actual data and not consecutive linking metadata), but that might
> require some more time and fine-grained applications considerations.
>
> One weakness from this impermanence feature is that it's actually
> application-dependent. For guix-system it's not very damaging (except if
> we want very low-level optimizations, like setting nodatacow on
> subvolumes with databases etc), but for guix-home, it makes things much
> more difficult. @Andrew Tropin : maybe that's something we could in RDE in
> a state-btrfs in (gnu home-services state) if we find a way to migrate
> directories to subvolumes safely and reproducibly.

Some notes about more progress I've done.

My attempt to also load the /home subvolume on tmfps has quite
progressed. I've created the following subvolumes :

;; App related (apps who doesn't entirely follow the XDG base directory
;; specification and save data or cache outside of XDG_DATA_HOME,
;; XDG_STATE_HOME and XDG_CACHE_HOME. Other users may need other app dirs.

/home/graves/.config/chromium
/home/graves/.config/emacs
/home/graves/.config/libreoffice
/home/graves/.config/guix
/home/graves/.ssh

;; XDG_CACHE_HOME, XDG_STATE_HOME, XDG_DATA_HOME (I'm using RDE)

/home/graves/.cache
/home/graves/.local

;; And some personal want-to-save directories.

/home/graves/archives
/home/graves/resources
/home/graves/projects
/home/graves/spheres

The only thing that seems to get in my way to achieve this properly
is... .guix-home! Which I don't want to backup since it's only a link
and that would require at least /home/graves/ to be snapshotted.

I thus have a proposition for discussion :
Make .guix-home XDG base dir compliant by storing a symlink
in $XDG_CONFIG_DIR/guix/home to /var/guix/per-user/$user/guix-home
instead of the current default of the symlink
in /home/$user/.guix-home to the actual object in the store.

This was discussed in a previous mail thread :
"RFC: Configurable placing of the ~/.guix-home symlink"
With Andrew concluding that

>  Back in the day, the implementation of Guix Home required a symlink in
>  home directory, right now due to improvements in symlink-manager and
>  reconfigure code it's probably not necessary and with a few patches
>  /var/guix/profiles/per-user/bob/guix-home/ can be used instead.

With a first glance, I think it's possible to do in the code, since the
home-run-on-first-login-service-type already gets the UID of the user,
and with the following guile function :

Scheme Procedure: passwd:name pw
    The name of the userid.

we should be able to get the name of the user and replace
~/.guix-home with /var/guix/per-user/$user/guix-home everywhere.
So the code where a hardlink is needed will be, and the "pleasing UX of
searching within guix home" would also be possible.

I also don't really see the reason why .guix-home shouldn't be
$XDG_CONFIG_DIR/guix/home since it's really user-specific and unique
(and XDG user dirs are too), unlike .guix-profile.

This may be the one of the only missing step to make the (manual and
only with directories (btrfs subvolumes), at least for now)
implementation of impermanence (a quick reminder of the idea implemented
by nix here : https://nixos.wiki/wiki/Impermanence) on with guix home, I
would appreciate some feedback comments on the idea ;) (another step
would be to actually activate the home environment on login in
home-shell-profile-service-type, but migrating .guix-home would be a
requirement).

-- 
Best regards,
Nicolas Graves

Re: btrfs recommended layout for snapshots?

[Andrew Tropin]

[-- Attachment #1: Type: text/plain, Size: 4125 bytes --]

On 2023-08-18 01:58, Nicolas Graves wrote:

> On 2023-08-16 10:10, Nicolas Graves wrote:
>
>> I guess it's possible to do the same with my home as well (thus only
>> saving actual data and not consecutive linking metadata), but that might
>> require some more time and fine-grained applications considerations.
>>
>> One weakness from this impermanence feature is that it's actually
>> application-dependent. For guix-system it's not very damaging (except if
>> we want very low-level optimizations, like setting nodatacow on
>> subvolumes with databases etc), but for guix-home, it makes things much
>> more difficult. @Andrew Tropin : maybe that's something we could in RDE in
>> a state-btrfs in (gnu home-services state) if we find a way to migrate
>> directories to subvolumes safely and reproducibly.
>
> Some notes about more progress I've done.
>
> My attempt to also load the /home subvolume on tmfps has quite
> progressed. I've created the following subvolumes :
>
> ;; App related (apps who doesn't entirely follow the XDG base directory
> ;; specification and save data or cache outside of XDG_DATA_HOME,
> ;; XDG_STATE_HOME and XDG_CACHE_HOME. Other users may need other app dirs.
>
> /home/graves/.config/chromium
> /home/graves/.config/emacs
> /home/graves/.config/libreoffice
> /home/graves/.config/guix
> /home/graves/.ssh
>
> ;; XDG_CACHE_HOME, XDG_STATE_HOME, XDG_DATA_HOME (I'm using RDE)
>
> /home/graves/.cache
> /home/graves/.local
>
> ;; And some personal want-to-save directories.
>
> /home/graves/archives
> /home/graves/resources
> /home/graves/projects
> /home/graves/spheres
>
> The only thing that seems to get in my way to achieve this properly
> is... .guix-home! Which I don't want to backup since it's only a link
> and that would require at least /home/graves/ to be snapshotted.
>
> I thus have a proposition for discussion :
> Make .guix-home XDG base dir compliant by storing a symlink
> in $XDG_CONFIG_DIR/guix/home to /var/guix/per-user/$user/guix-home
> instead of the current default of the symlink
> in /home/$user/.guix-home to the actual object in the store.
>
> This was discussed in a previous mail thread :
> "RFC: Configurable placing of the ~/.guix-home symlink"
> With Andrew concluding that
>
>>  Back in the day, the implementation of Guix Home required a symlink in
>>  home directory, right now due to improvements in symlink-manager and
>>  reconfigure code it's probably not necessary and with a few patches
>>  /var/guix/profiles/per-user/bob/guix-home/ can be used instead.
>
> With a first glance, I think it's possible to do in the code, since the
> home-run-on-first-login-service-type already gets the UID of the user,
> and with the following guile function :
>
> Scheme Procedure: passwd:name pw
>     The name of the userid.
>
> we should be able to get the name of the user and replace
> ~/.guix-home with /var/guix/per-user/$user/guix-home everywhere.
> So the code where a hardlink is needed will be, and the "pleasing UX of
> searching within guix home" would also be possible.
>
> I also don't really see the reason why .guix-home shouldn't be
> $XDG_CONFIG_DIR/guix/home since it's really user-specific and unique
> (and XDG user dirs are too), unlike .guix-profile.

I don't have all the context loaded in my head right now, but it's
probably possible now, and we can try to implement it.  Feel free to
send a patch and Cc me or continue the discussion on "RFC: Configurable
placing of the ~/.guix-home symlink".

>
> This may be the one of the only missing step to make the (manual and
> only with directories (btrfs subvolumes), at least for now)
> implementation of impermanence (a quick reminder of the idea implemented
> by nix here : https://nixos.wiki/wiki/Impermanence) on with guix home, I
> would appreciate some feedback comments on the idea ;) (another step
> would be to actually activate the home environment on login in
> home-shell-profile-service-type, but migrating .guix-home would be a
> requirement).

-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: btrfs recommended layout for snapshots?

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Nicolas,

On Mon, Aug 14, 2023 at 7:06 AM Nicolas Graves via Development of GNU
Guix and the GNU System distribution. <guix-devel@gnu.org> wrote:
>
> not snapshotting the rootfs
>   This would allow to simply care about only a few "user data"
>   directories

> I .. would be glad to find one

I believe Guix does a good job of managing system generations and only
snapshot user data. (My root is also on a faster ext4 file system, not
Btrfs.) Here is what I do. [1]

In order to avoid confusion with the live file system, I mount
snapshots volumes separately under /history. [2] My user data is
generally also encrypted and mounted to /home from networked folders
under /acct.

Hope that information is helpful to you.

Kind regards
Felix

[1] https://codeberg.org/lechner/system-config/src/commit/f847bb09093c945171814e18fd7d43ed94256336/host/wallace-server/operating-system.scm#L498-L516
[2] https://codeberg.org/lechner/system-config/src/commit/f847bb09093c945171814e18fd7d43ed94256336/host/wallace-server/operating-system.scm#L654-L659

Re: btrfs recommended layout for snapshots?

[Maxim Cournoyer]

Hi,

Felix Lechner via "Development of GNU Guix and the GNU System
distribution." <guix-devel@gnu.org> writes:

> Hi Nicolas,
>
> On Mon, Aug 14, 2023 at 7:06 AM Nicolas Graves via Development of GNU
> Guix and the GNU System distribution. <guix-devel@gnu.org> wrote:
>>
>> not snapshotting the rootfs
>>   This would allow to simply care about only a few "user data"
>>   directories
>
>> I .. would be glad to find one
>
> I believe Guix does a good job of managing system generations and only
> snapshot user data. (My root is also on a faster ext4 file system, not
> Btrfs.) Here is what I do. [1]

I agree, unless you very high requirements to minimize downtime in case
of failures, thus justifying the need of snapshotting the root fs and
backing it up to external storage, just snapshotting /home should be
good enough for most users.

I'd still opt for a flat subvolume layout to preserve the ability to
snapshot / at all in the future, in case you ever need to.  That's
tentatively covered/explained in info '(guix)Btrfs file system'.

> In order to avoid confusion with the live file system, I mount
> snapshots volumes separately under /history. [2] My user data is
> generally also encrypted and mounted to /home from networked folders
> under /acct.

Do note that you may run out of inodes if your store grows very large.
zstd compression also helps a lot ot keep /gnu/store growth in check,
and should reduce wear to flash based storage.

-- 
Thanks,
Maxim