I’ve been rolling back using it a few times and have kind of wondered if this is the “safe” way of restoring? It seems to have worked perfectly fine every time I’ve used it, so I’ve generally considered it “okay” since it’s worked.
Or should I be doing this another way?
I’ve stumbled upon the “arch” way of restoring snapshots but have lost that link.
Another question is (and I’ve been careful to avoid this) is how do I avoid kernel mismatch on rollback?
I never had problems with restored snapshots.
For kernel you must have /boot in the same root volume so that it’s part of the snapshot.
The EOS setup of btrfs is different subvolume layout i think. I wish i understood btrfs subvolumes better in order to explain but i won’t. I use btrfs on eos and have no issues with restoring snapshots using btrfs-assistant. You have to boot into a snapshot then restore from a snapshot that you want. I’m sure there are multiple methods of doing this. I use what I know how to do not stuff i don’t completely understand. If you are doing things the EOS way i wouldn’t worry. You can’t take everything from Arch and use it on EOS as some things may be slightly different setup such as the subvolume layout. I’ll let the btrfs experts answer since I’m not one.
It is as safe as I could make it. It moves the original subvolume to a backup and then takes a snapshot of the snapshot you are restoring. No data is removed in the process and if it hits a critical failure it tries to rollback.
If you are using grub, it won’t be an issue. If you are running systemd-boot, you need to chroot in and run reinstall-kernels.
Not the main maintainer here being like “yeah I made it as safe as I could” LOL.
I appreciate it!
and thank you for the info on restoring from a kernel mismatch!
Cannot the whole thing of taking snapshots be scripted in a way to backup the /efi too at the same time and thereby eliminating the need for chrooting when an snapshot is restored?
This was my thought as well, I don’t have time right now but I wonder if there’s a config for the pacman snapper plugin that you can include other snapper profiles as well?
I haven’t really looked into the matter that deeply. The idea just crossed my mind since I find the chrooting a bit of a hassle. So if there is a way to avoid it by backing up /efi somehow then why not.
I think there are some scripts/hooks out there that do this already.
I had considered adding pre-restore and post-restore hooks to Btrfs Assistant but I was a concerned about creating a situation where Btrfs Asssistant was running arbitrary code as root.
Alright, I understand. Thanks for explaining!
That’s understandable, IMHO this should maybe be more of a snap-pac thing instead?
And it does look like that’s also possible:
Edit: Nevermind on this, see below, arch does offer a guide to do this without remapping filesystem stuff.
Here we go, may need to be adjusted if you use /boot or /efi, not sure if you also need to backup the ucode in /boot as well even if you do use /efi?
Edit: The rsync seems to work, now to wait for the next time I get a kernel update and see if it does it’s thing, might be worth modifying it to also backup any time you’d have a kernel rebuild for whatever reason. but I think you can still get in with the same kernel version but old modules and do a rebuild. to get the downgraded modules.
My curiosity is would you still need to chroot to restore or could you copy the backup to /efi matching the backup date to your rollback date, then doing the rollback and have it “just work”.