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?
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?
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):
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.
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.
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 @.
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:
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
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.