How to backup and restore the partition table

Updated: August 26, 2015

For those of you new to Dedoimedo articles, you have a serious backlog of reading ahead of you, before you can confidently navigate the perilous waters of the Nerdy Bay, where words like partition and table are used with wild abandon.

But if you are in the groove, then you shall like this article. Today, we will talk about partition table backup and restore, why and when you should undertake this seemingly dubious step, and why it's useful. After me.


Note: Courtesy of FreeImages/Marcin Barlowski.


Sort of. So, if you happen to have a spare hard disk, with multiple partitions and/or frequent use that involves formatting, partitioning, moving and resizing of existing partitions, data copy and such, you may want to know that the integrity of those bits you don't want deleted is preserved when you go about changing those things that you do.

Indeed, whenever you fiddle with disks and partitions, there's a chance something might go wrong. You could get momentarily distracted or confused and delete the wrong device, or worse, format it, with all its precious data. We talked about data recovery in the past, now we will talk about something else.

What do you do if you suddenly destroy the partition table of a device? Or delete a partition? Now, at first glance, these may appear to be highly destructive operations, but they are quite innocent. In fact, most of the time, deletion of data, even formatting, is relatively innocent. It's not about what is stored on disk, but what you think is stored.

Deleting a file merely means de-indexing it from the disk log, making the space previously used by that file available for some other, future use. Deleting a partition is the same thing. You deallocate the markers that tell the disk, and subsequently, the operating system using the disk which pieces of the disk space are available for use, and which are considered free. And at the very top, there's the partition table. If you get this entry deleted, then the disk will appear as a raw, unused device, even though it may contain a perfectly sane and usable structure of partitions, filesystems, inodes, and actual data.

Going back to our initial statement, we want to be able to quickly and easily recover our partitions, should they somehow get lost. Which is why I'm going to show you how you can backup the partition table, both on MBR and GPT disks. We will then recover a seemingly dead disk. And finally, discuss the added value of this little geeky game.


We will start with regular disks, i.e. MBR-ed ones, with the standard ms-dos type partition table. In other words, you can have up to four primary partitions, one of which can be an extended partition containing logical partitions. In this case:

sfdisk -d /dev/<disk> > <disk>.layout

Here, we use the sdfisk command, with the dump (-d) option. The output is a human-readable file, listing the partitions, including the start sector, size and filesystem type. Quite useful if you ever need to recover something on your device. Of course, you can always go for automated recovery tools, but why not be sensible, and have a backup?

# partition table of /dev/sdc
unit: sectors
/dev/sdc1 : start=     4094, size=1248886786, Id= f
/dev/sdc2 : start=        0, size=        0,  Id= 0
/dev/sdc3 : start=        0, size=        0,  Id= 0
/dev/sdc4 : start=        0, size=        0,  Id= 0
/dev/sdc5 : start=     4096, size=122880860,  Id=83
/dev/sdc6 : start=122886144, size=122880000,  Id=83
/dev/sdc7 : start=245768192, size=122880000,  Id= 7
/dev/sdc8 : start=368650240, size=122880000,  Id=83
/dev/sdc9 : start=491540868, size=122865057,  Id= 7
/dev/sdc10: start=614414336, size=634476544,  Id=83

If your partitions are not aligned, you may see this warning:

sfdisk -d /dev/sdc > /root/sdc.layout
sfdisk: Warning: extended partition does not start at a cylinder boundary. DOS and Linux will interpret the contents differently.

For GPT, you should use sgdisk, which is readily available in all Linux distributions. Fdisk and sfdisk are not suitable for use with GPT devices, so remember that. Indeed, before doing any backups, you should execute the fdisk or sfdisk tools in a console windows to see whether they will display meaningful information in the running shell. If you encounter any sort of errors with sfdisk, you ought to try sgdisk next.

Using the dd command

Another way to accomplish the backup is manually, using the dd command. With MBR, you simply need to copy the first 512 bytes of the disk to a file, and later use it for restore. Indeed, with our /dev/sdc disk as a guinea pig:

# fdisk -l

Disk /dev/sda: 320.1 GB, 320072933376 bytes, 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000086a1

   Device  Boot    Start        End    Blocks   Id  System
/dev/sda1           4094  625141035 312568471    5  Extended
/dev/sda5           4096    8392703   4194304   82  Linux swap ...
/dev/sda6        8394752  417994751 204800000   83  Linux
/dev/sda7      417996800  520396799  51200000   83  Linux
/dev/sda8   *  520398848  625141035  52371094   83  Linux

Disk /dev/sdc: 639.4 GB, 639432130560 bytes, 1248890880 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00071ad3

   Device  Boot    Start        End    Blocks   Id  System
/dev/sdc1           4094 1248890879 624443393    f  W95 Ext'd ...
/dev/sdc5           4096  122884955  61440430   83  Linux
/dev/sdc6      122886144  245766143  61440000   83  Linux
/dev/sdc7      245768192  368648191  61440000    7  HPFS ...
/dev/sdc8      368650240  491530239  61440000   83  Linux
/dev/sdc9      491540868  614405924  61432528+   7  HPFS ...
/dev/sdc10     614414336 1248890879 317238272   83  Linux

And then, some wicked dd magic:

dd if=/dev/sdc of=/root/sdc.header bs=512 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.00104001 s, 3.9 MB/s

If you are not sure about sizes, then you should consult the header formats to figure out the exact values. For instance, Wikipedia entries on MBR and GPT tell us all we need to know. In general, you should use 512 and 16,384 bytes, respectively.


Let's mess up our device. Instead of using it as a source, we will use it as a destination, and write a bunch of zeros to it. This will simulate a scenario where the partition table got accidentally deleted or damaged, preventing the use of the hard disk. In reality, the actual damage might be bigger or more complex or completely irreversible, but in our case, let's focus on the partition table.

Again, we will use the dd command. BTW, should I remind you NOT to play with production devices, without first making sure you have ample, proven backups elsewhere? This is a very risky activity, and don't try it unless you know what you're doing.

dd if=/dev/zero of=/dev/sdc bs=512 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.00175504 s, 2.3 MB/s

If you remove the disk and reconnect it, and then run fdisk again, it will appear as if has no partitions. The output shown below isn't very useful, but that's what you'll see, with the exception of disk notation and size.

Disk /dev/sdc: 639.4 GB, 639432130560 bytes, 1248890880 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00071ad3

To restore the disk to a functional state, use dd to copy the saved header back to the device. Make sure you correctly specify the block size value and the count, because otherwise, you may cause more damage.

dd if=/location-of-saved-header of=/dev/sdc bs=512 count=1

Why would you want to do this?

All right, so there, a good question. Why should any sane person, i.e. non-Linux geek ever bother with this? Truth to be told, if you have a static setup, then you definitely need not to worry about your partition table. The chance of damage that isn't a complete failure of the disk is remote. And in that case, you will have bigger issues than just a messed-up partition table. This is a good opportunity to remind you of proper imaging and data backups as a philosophy and strategy in your daily computing.

Now, if you happen to be a somewhat more tech-savvy person and you do a lot of software testing, including Linux distro installations, partitioning and such, it might be prudent to keep a copy of the disk header, just in case something goes (lightly) wrong.


Now, this kind of rudimentary backup & restore is meaningless if you overwrite your real data. For instance, if you zero the disk, then nothing will help really. Furthermore, you must make sure not to perform any destructive actions before and during the restore operation, as you could accidentally delete important stuff.


There you go. This little tutorial won't make your salary any higher, but it may just boost you with the extra dose of confidence when it comes to working with hard disks and partitions and making changes. If you remember that all and any device is just a bunch of zeros and ones, then there's nothing sinister about them. You can backup portions of those long strings of binary code, you can overwrite them, you can restore them.

And so, the ability to backup and restore the partition table is a rather valuable addition in one's testing and tweaking arsenal, especially for people with an ever-changing setup of operating systems. If you do a lot of formatting and partitioning, sooner or later, you may end with the need to restore one of your devices. When that happens, it's always useful to have a proper backup. At the very least, you will save time. I hope you liked this.


You may also like: