I’ve been building test systems on real hardware to test and compare how to recover btrfs snapshots in multiple situations with both snapper/btrfs-assistant and timeshift on different distros.
I think that both will give you very similar capability if all you really care about is @home and @ subvolumes. Obviously, btrfs-assistant is way more configurable, but the average user like me will not use all those features.
I’m testing with KDE Plasma 6 in all cases and I install grub-btrfs in all cases.
Using timeshift or btrfs-assistant to create manual snapshots before critical changes is equally easy. So is manually restoring to a previous known good snapshot.
If I boot into a snapshot using grub, I can use timeshift or btrfs-assistant to restore to a know good snapshot without any issues. Depending on the distro, booting an ro snapshot from snapper can generate errors/warning but don’t keep you from running btrfs-assistant to restore. It is critical to immediately reboot after home and root are restored in both cases.
The one area if find a noticeable difference between timeshift and btrfs-assistant is in the case where your grub is messed up and you have to boot the system with a live usb stick.
What I found on Debian 13 was that the live image of KDE allowed me to apt install timeshift or btrfs-assistant. When I ran timeshift, it showed the first-run popup where you select rsync or btrfs with rsync defaulted. When you select btrfs, it immediately shows all your timeshift snapshots on your normal boot drive and you can restore them as normal.
However, btrfs-assistant didn’t seem to have a way to easily find the snapper snapshots.
So I wondering if I missed something? I plan on duplicating this on EOS today to see if it’s distro issue or app issue.
thanks for the tip. I could not do the test with EOS because too many of the Arch repos are not responding right now. I’ll do that later.
On Debian 13 I booted the USB drive for Debian13 KDE live and apt installed btrfs-assistant. As expected it would not run. So I had to do the following so btrfs-assistant would find the snapshots and restore them.
sudo mount /dev/nvme0n1p2 /mnt -o noatime,compress=zstd,subvol=@
sudo mount /dev/nvme0n1p2 /mnt/home -o noatime,compress=zstd,subvol=@home
At this point btrfs-assistant ran, knew about my snapper configs, and allowed me to restore to a known good @home and @ snapshot.
This is not as automatic as timeshift, but it works well if you remember the 2 mounts.
One option is to use Garuda’s live CD, which comes with Btrfs-assistant pre-installed.
I tried it a moment ago in vm with garuda-mokka-linux-zen-250826.iso
Thanks for the tip. The Garuda Live CD is a good tool for the Ventoy USB. My test was to boot it on my N100 box that was running Debian 13 KDE and opened a terminal then:
sudo mount /dev/nvme0n1p2 /mnt -o subvol=@
sudo btrfs-assistant-launcher
At that point btrfs-assistant saw both @ and @home and I restored both with a known good snapshot. I assume that the additional mount options were not needed because compress=zstd was used and in the metadata of the drive?
Right. All files present during the snapshot and their status (compressed or not) are preserved with the snapshot.
Only when files are rewritten will Btrfs use the new (or changed) compression options in the mount.
I got some very interesting results. On an EOS system with btrfs-assistant and snapper installed, I booted the Garuda iso and mounted the btrfs nvme on /mnt with subvol=@ and then ran btrfs-assistant-launcher.
It found my snapshots in the snapshot tab, but in the snapper tab there were no configs setup so you could not restore anything.
However, on Debian 13 system with btrfs-assistant I just had to mount the drive on /mnt with subvol=@ and it all worked.
What does work is booting from garuda live on a Debian 13 PC and mounting:
sudo mount /dev/nvme0n1p2 /mnt
sudo btrfs-assistant-launcher
So on a Debian 13 PC, a Garuda ISO boot finds the snapshots and configs and allows me to restore successfully, after the mount above.
On a Debian 13 PC, a Debian 13 live ISO boot finds the snapshots on the snapshots tab, but on the snapper tab it finds nothing due to not locating any configs. Since the Debian 13 live ISO doesn’t have btrfs-assistant, I had to apt install it first.
The is the same behavior I saw with a EOS PC booting the Garuda ISO. It couldn’t find any configs either. However, I can’t duplicate that result since I can’t install any AUR packages right now.
My properly functioning (EnOS host, Garuda live iso) garuda-mokka-linux-zen-250826.iso pre-installed is 2.2-1 according to pacman.
But sudo btrfs-assistant –-version tells 2.1.1
So it sounds like the solution is to create a bootable ISO USB flash key with a basic Linux distro that contains btrfs-assistant 2.2 and snapper to do the restore in an emergency.
