A couple questions about EndeavourOS BTRFS implementation

I’m in the process of wrapping my head around btrfs/snapper, and I’ve been looking into how distributions do it.

  • In Endeavour default install, the subvolumes are these:
SOURCE             TARGET
/dev/sda2[/@]      /
/dev/sda2[/@cache] ├─/var/cache
/dev/sda2[/@home]  ├─/home
/dev/sda2[/@log]   └─/var/log

In Garuda they are like this, with a seperate subvolume for root:


SOURCE             TARGET
/dev/sda2[/@]      /
/dev/sda2[/@log]   ├─/var/log
/dev/sda2[/@root]  ├─/root
/dev/sda2[/@home]  ├─/home
/dev/sda2[/@srv]   ├─/srv
/dev/sda2[/@cache] ├─/var/cache
/dev/sda2[/@tmp]   └─/var/tmp
  1. What are the practical implications of this with snapper? Garuda has a Snapper setup by default, has that got something to do with it? Debian also does it. Or is it just not very important?

  2. In laymans language, what’s the difference between flat and nested subvolumes, and what are the practical implications in a setup with snapper? And: is the Endeavour setup flat or nested?

  3. Say a person wanted to recreate the Endeavour setup in an Arch (with snapper) installation, will this be sufficient and achieve the intended result (I of course understand if Arch questions are frowned upon, in this case I figured it might be OK):

btrfs subvolume create /mnt/@
btrfs subvolume create /mnt/@home
btrfs subvolume create /mnt/@cache
btrfs subvolume create /mnt/@log
btrfs subvolume create /mnt/@snapshots

and

mkdir /mnt/home
mkdir -p /mnt/var/log
mkdir -p /mnt/var/cache
mkdir /mnt/.snapshots

and then mount those?

  1. A default EndeavourOS fstab looks something like this:

UUID=00abdf___ / btrfs subvol=/@,defaults,noatime,compress=zstd 0 0

What are those two zeroes at the end? How would one would one implement them during a CLI installation: by just typing two zeroes at the end of your mount options?

None.

No, garuda moved to snapper much later than they designed the subvolume layout.

Flat subvolumes are all the same level. Both EOS and Garuda use flat subvolumes. This is clear from your screenshots.

A nested subvolume is inside another one. For example, let’s use @home for example. You create a Downloads subvolume inside your @home it would look like this @home/Downloads

In most cases, it is better to not do this if you want to use snapper. It will just make your life more complicated. Snapper automatically creates nested subvolumes inside each subvolume you want to take snapshots of. Just use those instead.

The first one for dumps. This is almost always 0. The second one is the order to apply fsck. fack doesn’t work on btrfs so this should always be 0 for btrfs.

Yes.

4 Likes

Great, thanks! I had a suspicion those were flat layouts, it should be obvious by the looks. But I figured there might be some trick somewhere, certainly it wouldn’t be as simple as it looked, haha.

I think every single guide I’ve seen of pre-installation snapper setup makes a Snapper subvolume. Then they delete the .snapper mountpoint, before installing snapper. I’m not exactly sure why:

umount /.snapshots
rm -r /.snapshots/
snapper -c root create-config /
btrfs subvolume list /
btrfs subvolume delete /.snapshots
btrfs subvolume list /
mkdir .snapshots

If you don’t know why, don’t do it. Especially if you plan to use Btrfs Assistant.

Just look at all that nonsense. You have to do that again if you ever need to recreate the root config. The alternative just not doing any of that and using the default snapper config.

That being said, the reason you might want to do it is if you plan to use Suse-style rollbacks where they constantly move the pointer to the root filesystem to different snapshots. There is nothing wrong with that, but in my experience, that isn’t what most people do.

Yes, all the guides I’ve seen does that. Seems nice, and I want to have it just because. Most importantly, it is a learning experience.

I’m getting a basic grasp of the stuff, but not all the technical details, such as why it is necessary to delete it and let snapper recreate it, if I’ve understood the process correctly.

But what you’re saying about Btrfs Assistant makes me wonder. I plan to just use the command line, and when I’m comfortable with that, then I can use a GUI. I went to the Btrfs Assistant GitLab, but it didn’t say anything about subvolumes layout. Is Btrfs Assistant incompatible with the “Suse way”? If not, will my layout make things more difficult if I want to use Btrfs Assistant?

Because snapper creates a subvolume for the snapshots when it creates a config. If it can’t create the subvolume it refuses to create the config. So essentially what you are doing is letting snapper create the subvolume and then deleting it and replacing it with your own.

It can work with any subvol layout but it does not restore the root subvol by changing the default subvol as is done on suse.

Yes. Basically, you will have add a custom entry in a config file that tells btrfs assistant about the relationship between the subvols. You need to tell it that @snapshots holds the snapshots for @.

1 Like

Great, that is very nice to know, thanks!

1 Like

I also found those nonsense instructions on many tutorials. Could you please suggest a good tutorial?

1 Like

A good tutorial for what specifically?

To get started with snapper: in particular, its configuration, especially concerning the subvolume layout (avoiding the nonsense instructions above). Is the Arch wiki enough?

Snapper doesn’t require any special subvolume layout. The mistake is trying to do a special subvolume layout for snapper.

As far as subvolume layouts go, the default Calamares subvolume layout is actually a pretty good starting point. It creates 4 subvolumes:

  • /
  • /home - home is separate to allow for separate snapshot policies and restoration of user data from system data
  • /var/cache - This is separate so it can be excluded from snapshots. Taking snapshots here would just waste disk space
  • /var/log - This is separate so if you are forced to rollback your / subvol, you can still see the old logs and see went wrong

Other than that, it is mostly personal preference. I also add a subvolume for ~/.cache. In general, you want to create subvolumes for things that you desire a different snapshot policy for.

Some things to avoid:

  • Don’t create subvolume for /var on an Arch-based distro. This is will cause havoc because of the data pacman stores there.
  • Don’t create a subvolume for /boot. This will separate your kernels from your kernel modules.

Also be aware that you can name subvolumes whatever you like. You don’t need to name them with @ unless that is your preference.

As far as a tutorial goes. It depends what you want to accomplish. For a minimal setup you would need to do the following:

  1. Install snapper
  2. Create a config for each subvolume you want to snapshot
    • This is done via the command snapper create-config
    • To create a config for root you would use sudo snapper create-config /
    • To create a config for home you would user sudo snapper create-config -c home /home
    • As a side note, for all snapper commands when you exclude -c, it assumes the config named “root”

That is all that is needed for a basic snapper setup.

Next you need to decide how you want to take snapshots. Snapper can take snapshots in two automated ways using built-in functionality

  • It takes hourly snapshots which are then retained according to a schedule you set per config(snapper calls these “timeline snapshots”
  • It can take snapshots on boot

In addition to those two options, the package snap-pac will take snapshots before and after pacman transactions. Snapper can also be configured to only retain a certain number of these. Snapper calls these “number” snapshots.

There are several optional packages you can install:

  • btrfs-assistant - A GUI which handles all of the above except installing the packages
  • snap-pac - Described above, takes snapshots during pacman transactions
  • grub-btrfs - A tool for booting off snapshots when using grub
4 Likes

Many parts of the Arch wiki are good, but rest part of this wiki is how to restore snapshot in a flat/custom layout, but not Snapper default layout.

Ok, thanks!
That’s what I always do with timeshift as well!

So if I want to restore a snapshot I have to do something specific with snapper? (Given for granted that I have the subvolume layout of endeavouros)

You either need to restore it manually or use one of the tools that can restore it for you.

The big difference between timeshift and snapper is that timeshift does basically one thing in a fairly specific way. Snapper is much more of a blank canvas that you can use how you want to.

That is why it is hard to provide a highly specific tutorial. We all use it in different ways.

On the other hand, if you know how you want to use it, then a tutorial can be written.

Could you elaborate? As I understand it, certain layouts and proceedings in those instructions are needed if you want Suse-style rollback functionality.

Snapper default / nested layout , each snapshot is sub-subvolume in the .snapshots directory of a parent subvolume.

How to restore a snapshot for example @home:

@home subvolume has its children subvolume .snapshots.

  1. Move a broken/old subvolume out of the way e.g. @home to @home-backup:
$ sudo mv @home @home-backup
  1. Restoring @home:
$ sudo btrfs subvolume snapshot @home-backup/.snapshots/5/snapshot @home
  1. [IMPORTANT] Get the directory .snapshots back to the healthy @home subvolume
$ sudo mv @home-backup/.snapshots @home/

That is all.


Btrfs-Assisant can do for you.

I found this article/guide somewhat (as I’m not an expert) clarifying the rationale behind the “nonsense” subvolume layout and proceedings. I find it hard to believe that the writer would go through all this out of sheer ignorance, given that he or she sounds rather experienced. But you never know, of course. If so, I’d like to know.

Personally, the simpler the better. But it is nice to have tried it and see what it does, for the learning experience. The writer has very many subvolumes. Personally I’ve gone with the basic few ones that seems generally agreed upon to achieve the Suse-style rollback (and avoiding @var). But I need a break from subvolume layout worries, haha, so those installations will have to stay headless for a few more days.

https://www.ordinatechnic.com/distribution-specific-guides/Arch/an-arch-linux-installation-on-a-btrfs-filesystem-with-snapper-for-system-snapshots-and-rollbacks