This used to be easy before this UEFI thing. You just used dd to back up the first 63 sectors, then rsync to maintain a copy of everything in your / partition.
Is there any easy way to do the same now, where there is that efi partition mounted as /boot/efi and then the main ext4 partition with the / mountpoint, and the swap?
Use rsync to back up the files on both the root partition and the ESP (EFI System Partition). If you also want a copy of the partition table, you can use sgdisk's -b (backup) option to save a backup of the partition table to a file. Use -l (load) to restore. The sgdisk man page advises you to only restore the backup to the same disk, because the size may differ slightly even on a disk that is nominally the same size. You may be better off if you just recreate the partitions by hand anyway.
I think backing up a disk is even easier with UEFI, because everything but the partition table is in files, and not in msgic, off-partition sectors like the first GRUB stages.
I tend to use dd if=/dev/sda of=/my/backup/image.img bs=8M to image the entire device to an image file when I need the EFI to be intact on a drive I back up.
It may be a bit overkill (and time consuming), but it's the simplest way I know of.
If needed, you can mount the image as a loop device and browse/manage the files in there. gnome-disk-utility gives an easy to use GUI to handle that.
losetup(8) and kpartx(8) are your friends if you need to handle a partitioned image in console -- but even after wipefreespace(1) full image is usually a bit overkill indeed (unless one intends to put it exactly back)...
– Michael Shigorin
Feb 15 '18 at 11:17
This backup will do a copy of the partition table, and then an incremental backup of the contents of the partitions with rsync. The advantage over a blind, full backup with dd is that you can quickly update the backup very often and only the information that has changed will be updated, and also that you have all the files easily accessible in the copy, and you can modify them before restoring the backup, or rescue only some of them.
I'm using Debian Stretch (commands may have different names in, e.g. RedHat)
Everything here done as root, so watch out!:
su
See which hard drive is identified as sda, sdb, etc.
fdisk -l
I see that the laptop hard drive I want to back up is called /dev/sda (sda1, sda2... are the partitions).
Warning: Do NOT copy lines blindly. I assume the hard drive I want to back up is /dev/sda but that might not be your case.
Mount external hard drive where we want to store the backup copy:
By doing again fdisk -l I can see that its name is now /dev/sdb. Debian Stretch mounts it in /media/[username]/[whatever] but I prefer to mount it as root under /mnt/USB/, hence:
umount /media/[username]...
mkdir /mnt/USB/ # this is done only this first time
mount -t auto /dev/sdb1 /mnt/USB -rw
mkdir /mnt/USB/backup #this is done only this first time
mkdir /mnt/USB/backup/partition_table #this is done only this first time
mkdir /mnt/USB/backup/files #this is done only this first time
Determine if the partition table is of the type MBR or GPT
parted /dev/sda print
You see "Partition Table: gpt" or "Partition Table: msdos"
Back up the partition table to a file in the external hard drive
We can do a full binary backup of all the sectors where the partition table is stored:
dd if=/dev/sda of=/mnt/USB/backup/partition_table/backup-sda.mbr bs=512 count=1
(We'll later see how to restore this)
Remark: I prefer dd over sfdisk because the latter asks you to confirm if you want to write some changes to the partition table, and during my attempts I hit "Y" accidentally, so it is easy to screw up.
sgdisk --backup=/mnt/USB/backup/partition_table/gpt_partition_table.bin /dev/sda
(We'll later see how to restore this)
Incremental backup of all the files to the external drive:
This assumes that you, like me, have a single linux distro installed in the hard drive, and that all the information tree is hanging from / (please you knowledgeable linux guys, rewrite this in a more technical fashion). In my case, backing up everything from / solves the problem, because the efi partition is mounted as /boot/efi so its contents will be included in the backup too:
rsync -aAXv /* /mnt/USB/backup_of_laptop_hd/files --exclude={/dev/,/proc/,/sys/,/tmp/,/run/,/mnt/,/media/,/lost+found,/home//.gvfs,/var/tmp/,/home//.cache/,/home//.thumbnails//,/root/.thumbnails//,/root/.cache/,/home//.config/VirtualBox/*} --delete
Remark 1: This is an incremental backup, meaning that next time you do it, you don't need to copy everything again, but only the files that have changed will be automatically updated (and those deleted, will be deleted from the copy too).
Remark 2: All the options between {} are things that make no sense in a backup (e.g. temporary stuff) and also the virtual machines (I prefer to keep an encapsulated .ova file with each machine).
How to restore all that:
First, the worst case scenario in which you messed up the hard drive for good. You'd first restore the partition table (please skip this if your partition table is still alive) and you boot from a live USB:
Open a terminal in the live distro and check the name of the hard drive
fdisk -l
I will assume the hard drive of the laptop is still /dev/sda in the examples (warning, this time it could well be /dev/sdb).
If yours was an MBR table, then mount the external hard drive with the backup as we did above and then:
dd if=/mnt/USB/backup/partition_table/backup-sda.mbr of=/dev/sda
But, if yours was a GPT table, it would be:
sgdisk --load-backup=/mnt/USB/backup/partition_table/gpt_partition_table.bin /dev/sda
If you have already done this, or if your didn't need to do it because the partitions were intact, then it's time to restore all the files. This can also be used quite safely from a normally working system to restore it to the last backup:
rsync -aAXv /mnt/USB/backup/files/* / --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found,/home/*/.gvfs,/var/tmp/*,/home/*/.cache/*,/root/.cache/*} --delete
cp /mnt/USB/backup/files/vmlinuz / --preserve=all --remove-destination
cp /mnt/USB/backup/files/vmlinuz.old / --preserve=all --remove-destination
cp /mnt/USB/backup/files/initrd.img / --preserve=all --remove-destination
cp /mnt/USB/backup/files/initrd.img.old / --preserve=all --remove-destination
Remark: The last four lines I had to add them to the rsync command because, for some reason, files that are directly on the root of the tree are not restored. Also, when a folder is on / directly and it is erased in the computer, it will not be erased in the backup. This does not give any trouble (the corresponding files and libraries are not there any more, so nobody links or requires them) but it is ugly. Can anyone help me correcting the rsync syntax here?
Finally,
grub-install /dev/sda
Remark 1: While I have restored the system to a previous state with the above rsync syntax quite often, I have never needed to restore the partition table, so:
Remark 2: For the sake of simplicity, in the case of MBR partitions I have only include how to back up the primary partitions with dd. If you have extended partitions, then do the back up this way:
dd if=/dev/sda of=/mnt/USB/backup/partition_table/backup-sda.mbr bs=512 count=1
sfdisk -d /dev/sda > /mnt/USB/backup/partition_table/backup-sda.sfdisk
And restore the MBR and partition table this way:
dd if=/mnt/USB/backup/partition_table/backup-sda.mbr of=/dev/sda
sfdisk /dev/sda < /mnt/USB/backup/partition_table/backup-sda.sfdisk
ddto copy the partition table etc when they're doing a file copy of the root fs anyway. That just makes it harder to restore to a different-sized disk....better to just reboot to a rescue disk, partition, format, mount & restore, then chroot and run grub-install. – cas Feb 15 '18 at 01:24