System recovery after a crash using Timeshift

[GhX6GZMB]

Crashes happen, mostly from user incompetence (I mean me) and very rarely from hardware or software faults. Restoring a system to an earlier (functional) state is often not simple. The main problem is conflicts between UUIDs on a new install vs. the backup images, which make booting impossible. Here‘s a recipe for solving this.

This text presumes you have a Timeshift (rsync mode) backup snapshot created and available on external media. Only tested on Lubuntu 20.04LTS. Timeshift in rsync mode only works on ext4 file systems.


Scenario 1: User has changed/deleted/messed with something he/she shouldn‘t have; system no longer boots.

Live boot from DVD or USB drive and reinstall (x)ubuntu.
When getting to the partition settings, select „Manual partitioning“. Click on each partition, select „Edit“ and set the mount points. Under formatting select „Keep“!
This will preserve the partition UUIDs.
Finish the install and reboot, reinstall Timeshift and restore the backup image.
Done.


Scenario 2: The disk is so messed up that the above doesn‘t work, or the disk has had to be replaced.

Live boot from DVD or USB drive and install (x)ubuntu.
When getting to the partition settings, select „Manual partitioning“. Create your partitions and mount points as they were before the crash (restoring will also restore the old fstab!) . Under formatting, select „Format“ for each partition.
Finish the install and reboot, your partitions will now have new UUIDs.

Get the old UUIDs (on paper or print!) by inserting your Timeshift backup media and opening:

/media/<USER>/<mediaUUID>/timeshift/snapshots/<desiredsnapshot>/localhost/etc/fstab

Remove media.

Live boot again, open a terminal (ctrl+alt+T) and change the new UUIDs to the old ones using:

sudo e2fschk -f /dev/sdxy
sudo tune2fs /dev/sdxy -U aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee

For every partition.
sdxy is sda1, sda2, etc.
aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee is the old UUID.
You'll not see the changes (using blkid) before next reboot, but don't worry, they're there.

Live boot and install (x)ubuntu once again, this time selecting „Keep“ under formatting for all partitions. Don't forget to set the mount points again.
Install Timeshift and do your restore. Reboot and restore again to get the other users updated.
Done, your system should now be back to what it was before.


I‘m fully aware that three live boots and two installs may sound over the top. But believe me, this is so little effort and time compared to searching for all instances and other implications of the partition UUIDs and setting them right. The (x)ubuntu installer does this so much better.


And it‘s bullet-proof.

[TheFu]

And what do we do if we rework our storage completely? Suppose we switch from ext4 to zfs or LVM+xfs or BTRFS?

[GhX6GZMB]

And what do we do if we rework our storage completely? Suppose we switch from ext4 to zfs or LVM+xfs or BTRFS?

The second sentence reads: "Restoring a system to an earlier (functional) state is often not simple." Did I phrase this badly?

Honestly: if you want to rework your system, do you really need a system backup? Seems a bit far-fetched to me. You'll want to restore /home, but that's a different story.

My HOWTO is for someone wanting the system back as it was before.

[TheFu]

There are multiple installation types that don't use UUIDs in the fstab.

My intention was only to get some assumptions or prerequisites added to the 1st post that only systems which mount using UUIDs will work this way and where the types of storage used are unchanged. But for probably over 80% of normal desktop installs with EXT4 and EFI booting, this technique will probably work. Other file systems and legacy boot systems with a restore to a new HDD/SSD will probably fail. Or did I miss something?

[GhX6GZMB]

Good point. But Timeshift in rsync mode only works with ext4 file systems.