guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

btrfs recommended layout for snapshots?


From: Nicolas Graves
Subject: btrfs recommended layout for snapshots?
Date: Mon, 14 Aug 2023 16:05:35 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]