Re: btrfs recommended layout for snapshots?
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 signature.asc Description: PGP signature
Re: btrfs recommended layout for snapshots?
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?
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 רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: btrfs recommended layout for snapshots?
> 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?
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?
Hi Efraim and others, Efraim Flashner 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_minlatest archive_preserve12m 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?
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/ 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 רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: btrfs recommended layout for snapshots?
Hi, Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > Hi Nicolas, > > On Mon, Aug 14, 2023 at 7:06 AM Nicolas Graves via Development of GNU > Guix and the GNU System distribution. 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
Re: btrfs recommended layout for snapshots?
Hi Nicolas, On Mon, Aug 14, 2023 at 7:06 AM Nicolas Graves via Development of GNU Guix and the GNU System distribution. 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?
> - 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
btrfs recommended layout for snapshots?
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
