snapper rollback is specifically for OpenSUSE.
FYI:
btrbk is more flexible than snapper and also works for any distros.
What btrbk can do, what snapper can’t do:
But it requires manual configuration in just one configuration file /etc/btrbk/btrbk.conf
I tried it on a VM: I installed the AUR packages snapper-support (and btrfs-assistant). This automatically set up the snapshots for the root subvolume, the automatic snapshots for the pacman command, and the automatic grub menus for booting snapshots. I also tried booting a snapshot and restoring it with btrfs-assistant (and reboot). It all works like a charm! 
It seems too good to be true that I’m afraid I’m missing something 
Yeah, it is easy. 
Wil you also get the functionality described in this video, from the 20-minute mark? He’s restoring differences between pre- and post- snapshots when installing packages. This is useful to me.
Of course. snap-pac is doing taking the snapshots.
Then you can restore them either manually or via Btrfs Assistant.
You can also access and restore files from within those snapshots.
I guess I have no more excuses to switch to snapper from timeshift… 
Well thanks, great to know!
But sure there must be a reason all these people go for Suse-style layout? It can’t be as simple as that one “nonsense” guide first appeared, and now everyone’s copying it. These people claim that certain functionality needs a snapshots subvolume. I’d like to know what that is.
The Suse-style layout lets Snapper automatically detect any snapshots in its parent-subvolume without requiring any special configuration about where the snapshots reside.
That means, the Snapper layout would be an “easy automatic” setup for many people who don’t know this layout and don’t need to manually configure it.
Thanks! That gives me a clue on how to investigate this further. So it seems I don’t “need” Suse style layout. I’ve already implemented it on a couple of Debian netiso installs, for no other reason than that there seems to be easier to find info on the net when I need it. It was a nightmare with all that typing, haha. One of them, I had to give it 5 tries!
Btw, on a regular EndeavourOS btrfs install I end up with Timeshift (with timeshift-autosnap) snapshots that cannot be deleted from the gui, it just reports errors.
I didn’t look much into it, but started to entertain the idea that manual snapshots can occur at the same time as scheduled snapshots (hour, day, week). And if it would be cleaner just to have no schedules, and rely just on the pacman hook. It should be enough.
I guess perhaps the same thing goes for Snapper.
Not really. Snapper treats timeline snapshots separate from number snapshots and cleans them up independently.
If you use snapshots for anything more than “recovering from an update” then having scheduled snapshots is pretty important.
Great, I’m sold!
I use snapshots as a precaution on updates. And then I use them to roll back from experiments, and those often involves pacman. Which gives me the amount and spread of snapshots I really need. If the delete problem is a non-issue on snapper, I’ll set up scheduled snapshots, they are very nice to have.
I checked out the new official Arch installer today, for the first time. When you choose btrfs, you can choose a suggested subvolume layout, which is this:
[vlad@archlinux ~]$ findmnt -nt btrfs
/ /dev/sda2[/@] btrfs rw,relatime,ssd,space_cache=v2,subv
├─/var/cache/pacman/pkg
│ /dev/sda2[/@pkg] btrfs rw,relatime,ssd,space_cache=v2,subv
├─/.snapshots /dev/sda2[/@.snapshots] btrfs rw,relatime,ssd,space_cache=v2,subv
├─/home /dev/sda2[/@home] btrfs rw,relatime,ssd,space_cache=v2,subv
└─/var/log /dev/sda2[/@log] btrfs rw,relatime,ssd,space_cache=v2,subv
[vlad@archlinux ~]$
Maybe the Suse snapper-style will be a sort of informal standard in the Arch sphere, if Arch itself adopts it? Or are they victims as well of the “nonsense” spreading it the Linux world (sorry, couldn’t resist )?
The reason I ask is because, wouldn’t it be easier to write and use programs such as BRTFS Assistant (if that is the name for the snapper gui app), if it there were standards and it would work out of the box across Arch based distros?
That is actually slightly different than the above. The arch-install creator is using @.snapshots, not @snapshots
It all comes down this.
What do you want to happen when you restore a snapshot?
Do you want your root subvolume to stop being @ and instead move to @.snapshots/234/snapshot? If so, use a separately mounted volume for your root snapshots.
If however, you want to restore the snapshot to @, then don’t.
There are several problems with this.
@ in subvolume names isn’t a universally accepted convention.Of course, for your system, you should do what you want. I just see too many people doing that because they followed some random guide instead of actually having a good reason to do so.
Thanks! It is slowly starting to be a little bit clearer.
I’m probably overthinking it, but then again when I do that at least I pick up stuff I didn’t know. Thanks for the patience!
OK, in the end I just went with the EOS -style setup, as I have no need for a Suse -style one plus that the revolving default thing makes it more complex than I need, and learned the basic cli operation.
And now I’ve just gotta say that
btrfs-assistant + snap-pac + grub-btrfs = Totally Awesome!
Gotta love Linux! Thanks to everyone involved in helping a poor soul getting a basic grasp on btrfs!
@dalto
What is the difference then with btrfs-assistant, snap-pac and snapper-support?
btrfs-assistant - GUI tool for managing btrfs, snapper and btrfs maintenance
snap-pac - takes snapper snapshots when pacman transactions happen
snapper-support - Installs and configures snapper, snap-pac and grub-btrfs with the settings used by Garuda
I guess maybe i didn’t ask the question correctly. I was wondering if snapper-support sets it up to be the same as far as grub snapshots using grub-btrfs? I was using btrfs-assistant snapper and snap-pac. If you change and use snapper-support does that give you basically the same as using grub-btrfs?