Backup and Restore MBR and GPT Partition Tables [Guide]

Partition tables define how a disk is divided into sections. If the partition table gets corrupted – whether from a failed OS upgrade, accidental overwrite, or hardware fault – the entire disk becomes unreadable. Backing up MBR and GPT partition tables takes seconds and can save hours of recovery work.

Original content from computingforgeeks.com - post 98

This guide covers how to back up and restore both MBR (Master Boot Record) and GPT (GUID Partition Table) partition tables on Linux using dd, sgdisk, and sfdisk. These methods work on any Linux distribution.

Prerequisites

A running Linux system with root or sudo access
The gdisk package installed (provides sgdisk for GPT operations)
The util-linux package installed (provides sfdisk, fdisk, and lsblk – preinstalled on most distros)
A safe location to store backup files – a separate disk, USB drive, or remote server

Install sgdisk if it is not already available:

# Debian/Ubuntu
sudo apt install gdisk

# RHEL/Rocky/AlmaLinux/Fedora
sudo dnf install gdisk

MBR vs GPT – Quick Comparison

Before we get into the backup procedures, here is a quick comparison of the two partition table types. Knowing which scheme your disk uses determines which backup method to apply.

Feature	MBR	GPT
Max disk size	2 TB	9.4 ZB (effectively unlimited)
Max primary partitions	4 (or 3 + extended)	128
Boot mode	BIOS/Legacy	UEFI
Redundancy	None – single copy at disk start	Primary header + backup header at disk end
Location on disk	First 512 bytes (sector 0)	First 34 sectors + last 33 sectors

Step 1: Identify Your Disk and Partition Table Type

Start by listing all block devices to find the disk you want to back up. The lsblk command shows disks and their partitions in a tree format:

lsblk

The output shows each disk and its child partitions. Identify the target disk – typically /dev/sda for SATA/SAS disks or /dev/nvme0n1 for NVMe drives:

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   60G  0 disk
├─sda1        8:1    0    1G  0 part /boot
└─sda2        8:2    0   59G  0 part /

Next, check whether the disk uses MBR or GPT with fdisk:

sudo fdisk -l /dev/sda

Look at the “Disklabel type” line. It will say either dos (meaning MBR) or gpt:

Disk /dev/sda: 60 GiB, 64424509440 bytes, 125829120 sectors
Disk model: VBOX HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000a1bc3

You can also use blkid for a quick check:

sudo blkid -o value -s PTTYPE /dev/sda

This returns either dos (MBR) or gpt:

dos

Step 2: Backup MBR with dd (First 512 Bytes)

The MBR occupies the first 512 bytes of a disk. It contains the bootstrap code (first 446 bytes), the partition table (64 bytes), and the boot signature (2 bytes). Use dd to create an exact copy:

sudo dd if=/dev/sda of=~/mbr_backup.img bs=512 count=1

The command copies exactly 512 bytes from the start of /dev/sda to mbr_backup.img in your home directory:

1+0 records in
1+0 records out
512 bytes copied, 0.000512 s, 1.0 MB/s

Verify the backup file size is exactly 512 bytes:

ls -l ~/mbr_backup.img

The file should be exactly 512 bytes:

-rw-r--r-- 1 root root 512 Mar 22 12:00 /root/mbr_backup.img

You can also inspect the backup with hexdump to confirm the boot signature 55aa at the end:

hexdump -C ~/mbr_backup.img | tail -3

The last two bytes should show 55 aa – the standard MBR boot signature:

000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200

Step 3: Backup MBR with Extended Partition Data (First 1 MB)

The standard 512-byte MBR backup only captures the primary partition table. If your disk uses extended partitions (common on MBR disks with more than 4 partitions), the extended boot records (EBRs) are stored beyond the first sector. Backing up the first 1 MB captures all of this:

sudo dd if=/dev/sda of=~/mbr_extended_backup.img bs=1M count=1

This creates a 1 MB backup that includes the MBR, any EBRs for extended partitions, and the post-MBR gap that some bootloaders (like GRUB) use to store their stage 1.5 code:

1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00312 s, 336 MB/s

This is the recommended MBR backup approach when you are not sure whether extended partitions exist, as it covers everything the minimal 512-byte backup might miss.

Step 4: Backup GPT Partition Table with sgdisk

GPT disks should not be backed up with dd because the GPT structure spans the beginning and end of the disk, and the partition count can vary. The sgdisk tool handles all of this correctly. Back up the GPT partition table to a file:

sudo sgdisk --backup=~/gpt_backup.sgdisk /dev/sda

The output confirms the backup was created successfully:

The operation has completed successfully.

Verify the backup file exists and contains data:

ls -lh ~/gpt_backup.sgdisk

The file size depends on the number of partitions but is typically around 32-34 KB for a standard GPT layout:

-rw-r--r-- 1 root root 33K Mar 22 12:00 /root/gpt_backup.sgdisk

You can also print the current partition layout for reference – useful to have alongside the binary backup:

sudo sgdisk --print /dev/sda

This shows the disk GUID, partition GUIDs, sizes, and type codes in a human-readable format. Save this output to a text file for easy reference:

sudo sgdisk --print /dev/sda > ~/gpt_layout.txt

Step 5: Restore MBR from Backup

If the MBR gets corrupted, restore it by reversing the dd operation – swap if and of. This writes the backup back to the first 512 bytes of the disk:

sudo dd if=~/mbr_backup.img of=/dev/sda bs=512 count=1

The output confirms 512 bytes were written:

1+0 records in
1+0 records out
512 bytes copied, 0.000489 s, 1.0 MB/s

Warning: This overwrites both the bootloader code and the partition table. If you only want to restore the partition table (bytes 446-511) without touching the bootloader, use:

sudo dd if=~/mbr_backup.img of=/dev/sda bs=1 count=64 skip=446 seek=446

This writes only the 64-byte partition table, leaving the bootloader code intact. Useful when you have reinstalled a bootloader like GRUB but need the old partition layout back.

If you backed up the full 1 MB extended MBR, restore it the same way:

sudo dd if=~/mbr_extended_backup.img of=/dev/sda bs=1M count=1

After restoring, re-read the partition table so the kernel picks up the changes:

sudo partprobe /dev/sda

Step 6: Restore GPT Partition Table from Backup

Restore a GPT partition table from the sgdisk backup file. This writes both the primary GPT header (at the start of the disk) and the backup GPT header (at the end):

sudo sgdisk --load-backup=~/gpt_backup.sgdisk /dev/sda

The output confirms the restore completed:

The operation has completed successfully.

Verify the restored partition table matches your original layout:

sudo sgdisk --print /dev/sda

If the kernel has not picked up the restored partitions, force a re-read:

sudo partprobe /dev/sda

Important: The sgdisk restore requires the replacement disk to be at least as large as the original. If restoring to a different-sized disk, you may need to adjust partition sizes after the restore.

Step 7: Backup Partition Layout with sfdisk

The sfdisk tool provides another backup method that works with both MBR and GPT disks. It exports the partition layout in a text-based format that is easy to read and version control:

sudo sfdisk --dump /dev/sda > ~/partition_layout.dump

Examine the dump file to verify it captured the layout correctly:

cat ~/partition_layout.dump

For an MBR disk, the dump looks like this – showing the label type, identifier, and each partition’s start sector, size, and type:

label: dos
label-id: 0x000a1bc3
device: /dev/sda
unit: sectors

/dev/sda1 : start=     2048, size=  2097152, type=83, bootable
/dev/sda2 : start=  2099200, size= 123729920, type=83

The sfdisk dump format is particularly useful because it is human-readable and can be stored in a git repository alongside your infrastructure-as-code files. If you manage servers with tools like LVM, keeping partition layout backups in version control adds another layer of recoverability.

Step 8: Restore Partition Layout with sfdisk

Restore the partition layout from the sfdisk dump file. This recreates the partition table exactly as it was when the backup was taken:

sudo sfdisk /dev/sda < ~/partition_layout.dump

The output shows each partition being recreated:

Checking that no-one is using this disk right now ... OK

Disk /dev/sda: 60 GiB, 64424509440 bytes, 125829120 sectors

Old situation:
...

New situation:
Disklabel type: dos
Disk identifier: 0x000a1bc3

Device     Boot   Start       End   Sectors Size Id Type
/dev/sda1  *       2048   2099199   2097152   1G 83 Linux
/dev/sda2       2099200 125829119 123729920  59G 83 Linux

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

You can also clone a partition layout from one disk to another - useful when setting up identical disks for encrypted disk setups or RAID configurations:

sudo sfdisk --dump /dev/sda | sudo sfdisk /dev/sdb

This pipes the partition layout of /dev/sda directly into /dev/sdb, creating an identical partition structure on the second disk.

Step 9: Best Practices for Partition Table Backups

Backing up partition tables is only useful if the backups are stored safely and kept current. Follow these practices to make sure your backups are available when you need them:

Store backups off-disk - keep them on a different physical disk, USB drive, or remote server. A partition table backup stored on the same disk it describes is useless if that disk fails
Update after partition changes - re-run the backup commands after adding, removing, or resizing partitions
Label your backups - include the hostname, disk identifier, and date in the filename: webserver1_sda_gpt_20260322.sgdisk
Back up both formats - for GPT disks, keep both an sgdisk binary backup and an sfdisk text dump. The binary backup is faster to restore; the text dump is easier to inspect and version control
Automate with cron - for production servers, add a weekly cron job that backs up partition tables to your backup system
Verify backups periodically - use hexdump on MBR backups and sgdisk --print comparisons for GPT to confirm they are not corrupted

Conclusion

Partition table backups are a simple safeguard that takes seconds to create but can save a system from total data loss. For MBR disks, dd handles the backup and restore of the first 512 bytes or 1 MB. For GPT disks, sgdisk is the right tool since it handles both the primary and backup headers. The sfdisk tool works for both types and produces human-readable output suitable for version control.

For production servers, combine partition table backups with regular filesystem-level backups and full disk images. Store everything off-site, test restores periodically, and update backups after every disk layout change.