I’m thinking through the process needed to recover to a snapshot. I guessing if you have a working system you can:
mount /dev/sda2 -o subvolid=5 /mnt mv /mnt/@ /mnt/@.broken btrfs su sn /mnt/@snapshots/<n>/snapshot /mnt/@
What I’m wondering is if I boot a fresh EOS-ARM microSD card on my RPI4 and plug in my non-booting USB SSD, could I treat that just like when you boot a PC with the install ISO and recover the snapshots. I know it’s not grub-btrfs but it may work.
I use the standard subvol layout. @ and @home are the only ones I care about. I use snapper when I want to over complicate it and just manually do snapshots before I try something stupid. I’m getting used to Snapper and btrfs-assistant on my EOS PC I have played with the grub-btrfs and snap-pac and snap-pac-grub. But in RPI world, I’m thinking booting from a microSD with EOS and btrfs is about the only way to recover. I’m going to play with it.
I just tested it with success. I used snapper to create snapshots manually for both root and home. Then I installed Libreoffice-fresh.
I know I could have restored with btrfs-assistant, but I wanted to simulate the system failing to boot. I took a microSD card that had EOS xfce4 and btrfs on it and booted it. I inserted the USB3 SATA SSD and mounted /dev/sda2 on /mnt and then I could see the subvols. I moved @ to @.broken and then took a rw snapshot of the before-libreoffice-install snapshot and then shutdown and removed the SD card and rebooted.
The system came back but the start menu had a more traditional xfce theme. I then used btrfs-assistant to restore /home and then the theme of the menu was back to normal.
To clean things up, I did btrfs su set-default 265 /
which was the subvol number of the snapshot #3 of @. I also used looked at snapper ls to see where the + was and it was also 3. So I cleaned up snapper by doing snapper -c root --ambit classic rollback 3
I’m thinking that it might be possible to install btrfs-assistant on my microSD card and then I could have used it to do the restores, but no sure how it would know to use the snapshots of the USB SSD and not the SD card??
This example points out why I don’t understand in all the tutorials, people ignore /home snapshots. Every app I use put stuff in /home in some invisible directory and unless your also restore home to the same time frame as your / then you will have a mess.
I have a btrfs-assistant question regarding all this. First what I tested was booting up my microSD card version of EOS-ARM and installed btrfs-assistant on it. Then I plugged in my USB SATA SSD that contained EOS-ARM on it with all my snapper snapshots.
I then mounted the SSD with: mount /dev/sda2 /mnt -o subvolid=5
At that point I could use btrfs-assistant and change the Filesystem that it sees to the UUID for the SSD and not the SD. So it showed me all the root and home snapshots, but I could not restore from one as it said it was not one of it’s snapshots. Sort of like when you run btrfs-assistant on a normal PC it will not show anything in the browse/restore tab for root, only home.
This is because you didn’t let snapper create it’s nested subvolume to store snapshots which it does by default. You manually created a separate subvolume called @snapshots and mounted it. Btrfs Assistant supports this, but you need to edit the config file to tell it where to restore it to. Otherwise, it has no way of knowing to restore the snapshots stored in @snapshots to @.
One of the key design points of Btrfs Assistant is that it doesn’t require any special naming convention. In other words, the / filesystem can be mounted at @ or it can be mounted at bob, @rabbit or even something nested like eos/root. Because we allow this flexibility and Snapper doesn’t store the source subvolume in the metadata, it needs a config entry unless you use the default which is a nested .snapshots subvolume.
Interesting. I’ve been following the Archlinux snapper wiki on installing and creating the subvolumes. I’ve never really understood the creating, mounting umounting and deleting directories. I thought it had something to do with being able to boot to a snapper snapshot when you had boot problems. Not an issue on ARM, but if I could do my snapshots better on ARM and use btrfs for all the creating and restoring of snapshots from a bootable SD card with btrfs-assistant installed that would be great.
Are you saying that on ARM I could just forget snapper and use btrfs-assistant for snapshot creation for home and root? Or is there even such a distinction?
I did a fresh build and all I did prior to installing snapper and btrfs-assistant was to clear out the subvolid’s out of the fstab.
I got snapper all setup just using btrfs-assistant. Very cool. I then tried the whole test of:
Take a snapshot of root and home.
Then use btrfs-assistant to restore to the prior set of snapshots.
This worked great. The next test was to do the same thing but from a booted SD card. However, this time my EOS SD card had btrfs-assistant and snapper installed. Once I mounted the SSD on /mnt with -o subvolid=5, I launched btrfs-assistant and it could see all my snapshots of the SSD once I selected it’s UUID in the filesystem dropdown.
I just selected a pair of snapshots and restored them. Once I reboot the SSD and removed the SD card, I was back to normal. So either way works and for a broken root, the bootable SD card works great after you install btrfs-assistant and snapper.