How to recover using a full backup?

[Colin Watson]

On Mon, Sep 03, 2018 at 12:31:00AM +0200, Volker Wysk wrote:
> I'm making full backups of my system, on an external hard disc. It's a
> combination of incremental and differential backup (accoding to the definitions
> on wikipedia). So there isn't included everything in each backup, but only the
> difference to the last time (or one of the last times, to be correct). This
> works well.
> 
> The backup contains almost everything, excluding only things like /tmp,
> /home/.../tmp, /dev, /proc and a few others.

This is the kind of backup strategy I prefer too: it allows both picking
out individual files for spot-restores and restoring the entire system.

One caution: for full-system backups, you need to make sure that your
handling of various bits of file metadata is exactly faithful, and there
are some gotchas there.  You should check these things, both that the
backup preserves them, *and* that your restore strategy preserves them:

 * symlinks are preserved as symlinks rather than copying the contents
 * hardlinks are preserved (i.e. if two files share the same inode, then
   this is true in the backup as well)
 * extended attributes are preserved
 * modification times are preserved
 * numeric user and group IDs are used throughout, rather than assuming
   that user and group names can be looked up in matching passwd and
   group databases which probably won't be available when you're doing a
   full-system restore (I got this wrong once and it was a right pain to
   fix everything up manually)
 * sparse files are handled efficiently (this isn't vital, but if you
   have any sparse files on your system then you can end up with the
   restored system taking up a lot more disk space than it used to
   otherwise)

If you aren't careful about these things, you can end up with a restored
system that superficially and mostly works but that has some oddities
you'll run into over time.  For instance, failing to preserve extended
attributes will result in some programs not running with the correct
privileges, so e.g. mtr and gnome-keyring won't work properly.

You may want to make a backup of the disk's partition table structure,
e.g. using sfdisk.  You can just leave this in a file that gets backed
up along with the rest of the system.  Check that you have nothing in
other partitions that you can't reconstruct.

> Then, I would need to boot from a different drive, such as an USB stick, make a
> new file system on the (new or old) disc and restore the full backup in there.
> 
> I wonder how this is done. Just unpacking the backup doesn't do it. According
> to what I know, there should some "update-initramfs -u" and "grub-install"
> commands be necessary. But first some "mount --bind" commands are necessary,
> such that the configuration files are in the right places. And I don't know if
> there is more needing to be considered.

My usual strategy is to retain a copy of the UUID of the old file
system, which doesn't involve any extra backup work; you'll have it
somewhere in there, e.g. in /boot/grub/grub.cfg.  Then after restoring
files I grep for that in /etc and update any matching files to refer to
the UUID of the newly-created file system.  (Note that this is not
necessary in the case where you're simply reverting to an earlier state
after a catastrophic sysadmin failure, since in that case you don't need
to create a new file system.)

After that, you've got it all - the procedure goes roughly like this:

  mount --rbind /dev /mnt/dev
  mount --rbind /proc /mnt/proc
  mount --rbind /sys /mnt/sys
  chroot /mnt
  update-initramfs -u
  grub-install [possibly with suitable arguments]
  update-grub

Then unmount everything and reboot.  By definition you have recovery
media at this point, so even if you do need to iterate a little bit it
won't be too bad.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]