Setting Up Snapper

[blship]

Hello, I have been a long time garuda user and I really love the way snapper comes pre configured ootb and would really like to know how to achieve that on other arch based distros. Does anyone know how to do that and can make a tutorial?

[filo]

Hi there, welcome to the forum.
Probably you need:

Btrfs Assistant / Btrfs Assistant · GitLab

and relevant AUR package:
https://aur.archlinux.org/packages/btrfs-assistant
You may want to give a look also at our (Garuda) snapper-support for the configs and services:

snapper-support · main · Garuda Linux 🦅 / PKGBUILDs · GitLab

[BluishHumility]

This is a brief how-to written for another Arch-based distro that covers the main configuration details:

EOS with custom btrfs/snapper setup

Following those few steps will get you in the ballpark. From there, just dial in the specific settings you want and you should be good to go.

[blship]

Hi, thank you for the response, I went through the files and although I was not able to understand all of it, I did get some insights on the subject.

[blship]

Hello, thank you for your response. The post you’d linked has been most helpful to me in understanding what role does each component of the entire setup play and how it all comes together into something we’ve seen in Garuda, however, there’s no mention of the part where we restore or rollback to a working snapshot in case of a bad update or something. I did try to rollback via snapper-rollback but it said something like not setup for ambit or something like that that I don’t remember all that well. I also tried to restore it via the assistant and the booting straight into a snapshot via grub but it booted me into a read only snapshot, that doesn’t happen in Garuda. In Garuda, everything seems to just work flawlessly from creating a snapshot to restoring via the assistant or just straight up booting into a snapshot via grub and then just using that like normal. How do I setup that? If you could please help me out with that.

[BluishHumility]

@blship

there’s no mention of the part where we restore or rollback to a working snapshot in case of a bad update or something

There are 100 ways to restore a Btrfs snapshot. Which one you should choose depends on the subvolume layout you have set up, and also personal preference. Personally, I prefer the method of “move a subvolume out of the way, replace it with a rw snapshot” because it is easy to understand and works well.

In my opinion, using the mighty Btrfs Assistant to restore snapshots is the best way. It is easy, fast, and prevents making mistakes when you are doing the restoration.

To a restore a snapshot with this tool, click the “Snapper” tab, then the “Browse/Restore” tab within it. Choose the subvolume you want to restore a snapshot for, pick the snapshot you want to restore, and then click “Restore”.

You can restore a snapshot with this same method regardless of whether you are booted into the subvolume you are restoring a snapshot for, or just mounting the Btrfs partition when booted to the live environment or booted to a Btrfs snapshot. Btrfs Assistant has command-line options as well, if you want to restore a snapshot from a TTY for example.

@blship

I did try to rollback via snapper-rollback but it said something like not setup for ambit or something like that that I don’t remember all that well.

My understanding is this tool is specifically for restoring Btrfs snapshots if you have chosen to use the subvolume layout described in the ArchWiki here: https://wiki.archlinux.org/title/Snapper#Suggested_filesystem_layout

subvolid=5
  |
  ├── @ -|
  |     contained directories:
  |       ├── /usr
  |       ├── /bin
  |       ├── /.snapshots
  |       ├── ...
  |
  ├── @home
  ├── @snapshots
  ├── @var_log
  └── @...

To be clear, this is not the subvolume layout that Snapper uses by default. By default, the .snapshots subvolumes are nested inside the subvolume the snapshots are for–not set as a top-level subvolume like that.

Unless you explicitly set up this kind of subvolume layout (with a top-level subvolume for snapshots), I would suggest not using the Snapper-Rollback tool.

@blship

and the booting straight into a snapshot via grub but it booted me into a read only snapshot

Garuda Linux is configured to use overlayfs when booting a Btrfs snapshot from Grub. See this note from the grub-btrfs page for more information about that: grub-btrfs/initramfs/readme.md at master · Antynea/grub-btrfs · GitHub

If your Arch-based distro is using mkinitcpio, you can set this up by adding the grub-btrfs-overlayfs hook to /etc/mkinitcpio.conf:

Edit the file /etc/mkinitcpio.conf
Added hook grub-btrfs-overlayfs at the end of the line HOOKS.

For example :
HOOKS=(base udev autodetect modconf block filesystems keyboard fsck grub-btrfs-overlayfs)

Then regenerate the initramfs, and create some Btrfs snapshot with this new image.

If your distro uses dracut, you can boot to them with overlayfs by setting the rd.live.overlay.overlayfs=1 kernel parameter. You can set this kernel parameter for Btrfs snapshots only by using the GRUB_BTRFS_SNAPSHOT_KERNEL_PARAMETERS option in /etc/default/grub-btrfs/config.

See the highlighted lines here: grub-btrfs/config at master · Antynea/grub-btrfs · GitHub Essentially you just need to uncomment that line in /etc/default/grub-btrfs/config and then run sudo /etc/grub.d/41_snapshots-btrfs to generate a new snapshot submenu.