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?

  • 1
    This is what Clonezilla is for. BTW, I can't see any reason why anyone would bother using dd to 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, 2018 at 1:24

3 Answers 3


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.

  • Would it work if I only dd the first X sectors (where X is ???) so that the efi boot and the partition table would reappear, and the rest with a normal rsync command?
    – Mephisto
    Feb 14, 2018 at 20:31
  • It might, but I'm not familiar enough with how the different partition table setups handle it to be able to give you a concrete answer to that. I might actually do that if I knew how to do it safely. ^_^;
    – Mio Rin
    Feb 14, 2018 at 20:35
  • Thanks for your help. I re-wrote the question because I wanted some kind of copy where one could read and search for individual files, so you might want to adapt the answer.
    – Mephisto
    Feb 15, 2018 at 2:04
  • 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)... Feb 15, 2018 at 11:17
  • 1
    @MichaelShigorin That tends to be my use case when I make this kind of complete backup. (create image->do dumb stuff->restore image)
    – Mio Rin
    Feb 15, 2018 at 12:49

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!:


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

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

  4. Back up the partition table to a file in the external hard drive

    In case you have an MBR table (Partition Table: msdos):

    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.

    In case you have a GPT table

    sgdisk --backup=/mnt/USB/backup/partition_table/gpt_partition_table.bin /dev/sda

    (We'll later see how to restore this)

  5. 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).

  6. 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?


    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:

  1. You are at your own risk and,
  2. Please feel free to suggest edits to improve this answer.

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .