ubuntu 18.04 btrfs hw2018 server snapper xsuperseded

** 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 anymore. apt should have triggered a snapshot, and thoses changes can be reverted.

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 ncdu is really usefull, but let’s do it:

1. Create a ~fake~ problem

   sudo apt-get install -y ncdu
   

2. 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         |     
   

   apt has created a pre/post snapshots with numbers 257 and 256

3. Revert the changes

   sudo snapper undochange 256..257
   create:0 modify:6 delete:96
   

   ncdu is 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 filesystem layout.

However, since we’ve got snapshots, we can still recover manually from catastrophic failures.

1. Make sure you’ve got a bootable media for your machine.
2. Make sure you’ve got a recent backup.
3. NO, liten to me NOW!, make really really sure you’ve got a working backup and a bootable media for your machine, always.
4. Make sure you’ve got a good snapshot of your system, and /boot is 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
   ...
   

5. Now I’m sure /boot is in my snapshots, let’s create a fake problem:
6. Create a fake problem

   sudo rm /boot -rf
   

7. Now reboot (won’t work)
8. Reboot on your bootable media, select Rescue a broken system
9. Do as you do when you installed the system
10. Assemble the RAID array (automatic will do), then select your root device, mine is /dev/root/root
11. Execute a shell in the installer environment
12. Umount /target it is mounted with a wrong subvolume argument, and remount it

    umount /target
    mount /dev/root/root /target
    

13. Make a snapshot of the broken system

    btrfs create subvolume snapshot -r /target/@ /target/@/.snapshots/broken
    

14. Restore

    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
    

15. reboot (should work), then let’s have a look at snapper

    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.

~~~

Question, remark, bug? Don't hesitate to contact me or report a bug.