** This post has been updated: simpler rollbacks**
snapper and how to deal with problems
snapper undochanges for small problems
Let’s suppose you’ve updated a package, and the new version does not work
apt should have triggered a snapshot, and thoses changes can be
I don’t have a situation like this on my system, but let’s pretend I have one,
by installing a software, for instance
ncdu. It’s a bad example, since
is really usefull, but let’s do it:
- Create a ~fake~ problem
sudo apt-get install -y ncdu
- Identify the snapshots
snapper list ... single | 255 | | Tue 15 May 2018 07:00:09 PM CEST | root | timeline | timeline | pre | 256 | | Thu 17 May 2018 08:24:12 PM CEST | root | number | apt | post | 257 | 256 | Thu 17 May 2018 08:24:19 PM CEST | root | number | apt |
apthas created a pre/post snapshots with numbers 257 and 256
- Revert the changes
sudo snapper undochange 256..257 create:0 modify:6 delete:96
ncduis not installed anymore, success!
snapper rollback for bigger problems ⚠
snapper rollback is not supported on ubuntu, mainly
because SUSE Linux (the main contributor of
snapper) uses a different
However, since we’ve got snapshots, we can still recover manually from catastrophic failures.
- Make sure you’ve got a bootable media for your machine.
- Make sure you’ve got a recent backup.
- NO, liten to me NOW!, make really really sure you’ve got a working backup and a bootable media for your machine, always.
- Make sure you’ve got a good snapshot of your system, and
/bootis on the snapshot
sudo touch /boot/test snapper create -c timeline -d "about to destroy the system" snapper list ... single | 260 | | Thu 17 May 2018 09:00:12 PM CEST | root | timeline | timeline | single | 261 | | Thu 17 May 2018 10:00:31 PM CEST | root | timeline | timeline | single | 262 | | Thu 17 May 2018 10:50:42 PM CEST | pim | timeline | about to destroy the system | ... snapper status 261..262 ... +..... /boot/test ...
- Now I’m sure
/bootis in my snapshots, let’s create a
- Create a
sudo rm /boot -rf
- Now reboot (won’t work)
- Reboot on your bootable media, select Rescue a broken system
- Do as you do when you installed the system
- Assemble the RAID array (automatic will do), then select your root device,
- Execute a shell in the installer environment
/targetit is mounted with a wrong subvolume argument, and remount it
umount /target mount /dev/root/root /target
- Make a snapshot of the broken system
btrfs create subvolume snapshot -r /target/@ /target/@/.snapshots/broken
btrfs property set -ts /target/@/.snapshots/261/snapshot ro false mv /target/@ /target/@_broken mv /target/@_broken/.snapshots/261 /@ mv /target/@_broken/.snapshots /@ umount /target
- reboot (should work), then let’s have a look at
snapper create -c timeline -d "system restored" snapper list ... single | 260 | | Thu 17 May 2018 09:00:12 PM CEST | root | timeline | timeline | single | 262 | | Thu 17 May 2018 10:50:42 PM CEST | pim | timeline | about to destroy the system | single | 263 | | Thu 17 May 2018 10:50:42 PM CEST | pim | timeline | system restored |
Spapshot #261 is not in the list anymore, since we have moved it to @, but our system is fixed.