Restoring backups and effect on GRUB

[Colin Watson]

On Sat, Jul 27, 2019 at 01:15:05PM -0700, Kevin O'Gorman wrote:
> I'm working on backup scripts, and want to make sure I understand the
> consequences of what I'm doing.  In particular, I have still not decided
> how I'm going to back up my / partition: tar/dar or dd,
> and I'm wondering what effect there is on GRUB if a partition is moved,
> resized, or restored from a  tar/dar archive, because I'm thinking some of
> the above operations would change where the kernel is.  I'm unclear about
> how GRUB locates the kernel and any other boot files, and whether it can
> follow the directory structure or if instead it knows the LBA blocks where
> the files were originally stored.

(I'm assuming you're using GRUB 2 rather than some long-obsolete
version.)

GRUB has file system parsing code.  In general it doesn't just encode
LBA block numbers or whatever.  There is one exception in some cases: it
has to locate its own core image somehow, since that's what contains the
file system parsing code.

If you're using UEFI, then the core image lives in the EFI System
Partition (typically mounted on /boot/efi) at a specific path which the
firmware is told to boot from; you should back up /boot/efi, but
otherwise there are no hardcoded offsets in this case.

If you're using the traditional BIOS boot mode, then booting typically
starts with a tiny first-stage loader right at the start of the disk,
which encodes the starting sector of the GRUB core image.  The first
sector of the core image in turn has a list of other sectors to read.
Once the core image is running it can then do everything else by parsing
file systems properly.

You shouldn't have a problem with any of this when merely moving or
resizing a partition (unless you manage to overwrite the GRUB core image
I suppose, but as long as you steer clear of the first megabyte of the
disk you'll more than avoid that).  Restoring can involve some work,
though.  As well as the above, restoring a file system from backup may
(depending on how you do it) change its UUID, and there are some places
(including GRUB's configuration, but possibly also /etc/fstab and
/etc/initramfs-tools/conf.d/resume) where that UUID is hardcoded.


My usual practice is to fix this all up at restore time; I always
restore using a live USB stick or similar so I have plenty of tools
available.  After I restore the file system contents, let's say to /mnt,
I do this:

  for x in dev proc run sys; do mount --rbind "/$x" "/mnt/$x"; done
  # On UEFI, you'll also need to make sure that your EFI System
  # Partition is mounted on /mnt/boot/efi.
  chroot /mnt

Then in the chroot:

  # On UEFI:
  dpkg-reconfigure grub-efi-amd64
  # ... or on BIOS (do one or the other of these, not both); this one
  # may prompt you if the disk's identity changed:
  dpkg-reconfigure grub-pc

  # This is a good point to fix up any places where the old UUID was
  # hardcoded.  I usually just do this by hand because there aren't
  # many.  You can get the new UUID from "blkid" if you need it.  Then:
  update-initramfs -u

Now exit the chroot, and tidy up:

  for x in dev proc run sys; do umount -l "/mnt/$x"; done
  # On UEFI, unmount /boot/efi as well.

You can now reboot and see what happens.  If you've made a mistake, you
still have the live USB stick to hand and you can get back in to fix
things up.

While this is certainly more than zero work, it's short enough to fit on
a couple of sticky notes (I just do it from memory, though I recognise
not everyone will quite manage that ...).

Regarding file-system-level backups versus dd or similar, I still
recommend file-system-level backups: they have the massive benefit (for
me at least) that it's completely trivial to just mount the backup disk
and fish out a particular file from a particular backup version, which
is something I do a lot more frequently than a full restore since
fat-fingering a single file by accident happens a lot more often than
trashing an entire system.  And although dd-based backups would preserve
the file system UUID, they might change other aspects of the disk's
identity, so at least on BIOS systems you'd still want to reconfigure
grub-pc as above.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]