fdisk to dump the table to a file with sfdisk -d, then restore it with sfdisk /dev/sdX < backup.txt. For GPT disks, use sgdisk to backup with -b and restore with -B. This process also preserves Linux partition labels when handled correctly, ensuring your system boots and mounts volumes as expected after a recovery.
Understanding Partition Table Formats
The method you choose depends entirely on whether your disk uses Master Boot Record (MBR) or GUID Partition Table (GPT). These two standards store partition information differently, requiring different tools for safe extraction and reapplication.
MBR is an older standard that stores partition data in the first sector of the disk. It has limitations, such as supporting only four primary partitions per disk and not handling drives larger than 2TB efficiently. Most legacy systems and many external drives still use this format. When working with MBR, the primary tool is fdisk, which provides both interactive and non-interactive capabilities.
GPT is part of the UEFI standard and is the modern default for most Linux distributions. It supports up to 128 partitions per disk and handles large drives effectively. GPT stores multiple copies of the partition table at the beginning and end of the disk for redundancy. The recommended tool for GPT operations is sgdisk, which is more robust and less prone to human error than interactive tools like gdisk.
Before proceeding, ensure you know which type of disk you are managing. You can check this by running sudo fdisk -l /dev/sdX. Look for "Disklabel type: dos" for MBR or "Disklabel type: gpt" for GPT. If you are unsure, backing up both the MBR and GPT structures is possible but often unnecessary unless you are converting between formats.
Backing Up MBR Partition Tables with sfdisk
The sfdisk utility is designed specifically for scripting and non-interactive operations, making it ideal for backups. While fdisk is interactive, sfdisk can output the entire partition layout in a readable format that can be redirected to a text file.
To create a backup of your MBR partition table, open a terminal and run the following command, replacing /dev/sdX with your actual device identifier:
sfdisk -d /dev/sdX > mbr_backup.txt
This command dumps the partition table definition into mbr_backup.txt. The output includes the start and end sectors, size, type codes, and any labels assigned to partitions. It is crucial to save this file to a location outside the target disk, such as an external USB drive or a network share, because the source disk may become corrupted or overwritten during restoration.
If you need to include partition labels in your backup, note that sfdisk does not always preserve ext4 filesystem labels directly in the partition table dump unless they are stored in the partition metadata. However, the structural integrity of the partitions is preserved. For a complete disaster recovery plan, consider also backing up the filesystem superblocks separately if label preservation is critical.
For more context on handling specific partition issues, see How to Access Data on an External SSD Drive with MBR Only? regarding troubleshooting existing MBR setups.
Restoring MBR Partition Tables
Restoring the MBR table is straightforward but dangerous. Once executed, the previous partition layout will be overwritten. Ensure no partitions from the current live system are mounted from the target disk, or use a live USB environment to perform the operation.
To restore, use the -f flag to force the write, ignoring warnings about overwriting existing data:
sfdisk /dev/sdX < mbr_backup.txt
After restoration, you must update the kernel's view of the partition table. Run partprobe or reboot the system. The partitions will appear again with their original sizes and types. Note that file contents remain untouched; only the map telling the OS where those files live is restored.
Backing Up GPT Partition Tables with sgdisk
For GPT disks, sgdisk is the preferred tool due to its ability to handle the dual-partition-table structure of GPT safely. It also provides better validation checks than other tools.
Create a backup using the -b option, which saves the backup to a binary file. Binary backups are smaller and faster to restore than text-based dumps:
sgdisk -b=/path/to/gpt_backup.bin /dev/sdX
This command creates a binary snapshot of the GPT header and partition entries. The binary format ensures that all UUIDs, unique identifiers, and attributes are preserved exactly as they are. This is particularly important for RAID arrays or LVM setups where partition UUIDs are referenced explicitly.
Additionally, sgdisk can export the partition table to a text-like format using -o if you prefer a human-readable record, but the binary format is recommended for reliability:
sgdisk -o=/path/to/gpt_backup.txt /dev/sdX
See Reassembling Disk Partitions from Separate Images in Linux for techniques on recovering data when partition structures are severely damaged.
Restoring GPT Partition Tables
Restore the GPT table using the -B option followed by the path to your backup file:
sgdisk -B=/path/to/gpt_backup.bin /dev/sdX
Like the MBR restoration, this overwrites the existing GPT headers. After execution, run partprobe or reboot to ensure the operating system recognizes the restored layout. Because GPT stores redundant copies, sgdisk automatically repairs the secondary copy at the end of the disk during restoration.
If you have customized GRUB installations or complex boot configurations, refer to Installing GRUB for a New Custom-Created Linux OS (Yocto) on Partitioned sda to understand how partition changes might impact boot loaders.
Handling Linux Partition Labels
Partition labels (volume names) are distinct from the partition table itself. While sfdisk and sgdisk preserve the partition structure, they do not always guarantee the persistence of filesystem-specific labels like those used by ext4 or NTFS. To back up and restore labels explicitly, use the e2label command for ext2/3/4 filesystems.
To view the current label of a partition:
sudo e2label /dev/sdX1
To set a new label:
sudo e2label /dev/sdX1 my_label
For comprehensive partition management including labeling, review How to Partition Disk for Manjaro: A Step-by-Step Guide which covers best practices for naming and organizing drives.
Frequently Asked Questions
Can I restore a GPT backup to an MBR disk?
No, you cannot directly restore a GPT backup to an MBR disk because the underlying data structures are incompatible. You would need to convert the disk to GPT using sgdisk -g /dev/sdX before applying the backup, or recreate the partition table manually using MBR-compatible tools.
Does restoring a partition table delete my files?
No, restoring the partition table only changes the map of where partitions start and end. Your actual file data remains intact on the disk sectors. However, if the restored table points to different offsets than the original, the OS may fail to mount the partitions correctly until the table matches the actual data layout.
What happens if I lose my GPT backup and the disk becomes corrupt?
If the GPT primary header is corrupted and you have no backup, you can attempt to repair it using sgdisk --repair /dev/sdX. This tool looks for the secondary copy of the GPT table at the end of the disk and attempts to rebuild the primary header based on that information.
Is it safe to run sfdisk while the system is booted from the same disk?
It is highly unsafe. Restoring a partition table while the OS is actively using those partitions can lead to severe data corruption. Always perform restorations from a Live USB environment or ensure the target disk is completely unmounted and not in use by the running kernel.
How do I verify my backup file is valid?
For sfdisk text backups, you can dry-run the restoration by piping the file into sfdisk without writing to the disk, though this is tricky. For sgdisk binary backups, you can inspect them using sgdisk -i /dev/sdX after restoring to compare UUIDs and sizes against known good values, or simply test on a spare drive first.