Backup and Restore a Linux Partition Table with sfdisk

A damaged or accidentally overwritten partition table can make a healthy disk look empty even when the data blocks are still there. sfdisk from util-linux can dump that layout to a text file, restore it later, or copy the same geometry to another disk. I ran every command below on RHEL 10.2 using loop-backed test disks; the same sfdisk workflow applies on Debian and Ubuntu once the fdisk package is installed.

Quick reference: sfdisk backup and restore

On Debian or Ubuntu, install sfdisk when it is missing—the apt command installs the fdisk package that provides it:

sudo apt install fdisk

The rest of this guide uses the same commands on every distribution.

What a partition table backup actually contains

The partition table is the index at the start (and, for GPT, also near the end) of a disk. It records where each partition begins, how large it is, and what type it is. A text dump from sfdisk --dump can include:

• Partition start sectors and sizes
• MBR partition type codes or GPT type GUIDs
• GPT disk label ID and per-partition UUIDs
• GPT partition names when present

It does not contain:

• Files or directories inside partitions
• Filesystem superblocks or journal data
• LVM physical volume or volume group metadata
• Application or database contents

If you only need files, use a normal Linux partition backup tool for filesystem data. If you need the map that tells Linux where partitions live, sfdisk --dump is the right layer.

Check whether the disk uses GPT or MBR

Before you back anything up, confirm the label type on the disk you are about to touch. fdisk -l prints it near the top of the report:

sudo fdisk -l /dev/sda

Sample output:

Disk /dev/sda: 512 MiB, 536870912 bytes, 1048576 sectors
Disklabel type: gpt
Disk identifier: 59C4E59B-0C92-4D29-9E01-6D399F290C6F

Device        Start     End Sectors  Size Type
/dev/sda1      2048  262143  260096  127M Linux filesystem
/dev/sda2    262144  524287  262144  128M Linux swap
/dev/sda3    524288 1046527  522240  255M Linux filesystem

Disklabel type: gpt means a GUID Partition Table. Disklabel type: dos means a legacy MBR layout. Modern sfdisk handles both; you do not need a separate tool per label type.

The lsblk command is useful when you want partition type and UUID columns in one view:

lsblk -o NAME,SIZE,TYPE,FSTYPE,PTTYPE,PARTTYPE,PARTUUID /dev/sda

On a GPT disk you will see PTTYPE set to gpt and a PARTUUID on each partition row.

Back up a partition table with sfdisk --dump

The primary backup workflow is a text dump you can store in Git, email, or configuration management:

sudo sfdisk --dump /dev/sda > sda-partitions.dump

The file is plain text. A GPT example looks like this:

label: gpt
label-id: 59C4E59B-0C92-4D29-9E01-6D399F290C6F
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 1048542
sector-size: 512

/dev/sda1 : start=        2048, size=      260096, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=5D4BCEC6-CB41-4F03-B603-D2D8E3820307, name="primary"
/dev/sda2 : start=      262144, size=      262144, type=0657FD6D-A4AB-43C4-84E5-0933C84B4F4F, uuid=793244EB-4449-4DD6-9D60-F191C0DBFA4A, name="primary"
/dev/sda3 : start=      524288, size=      522240, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=914D6E2E-6B18-48D2-A11C-5B51608BA994, name="primary"

An MBR disk uses label: dos and hexadecimal type codes instead of GPT GUIDs:

label: dos
label-id: 0xf0a983e5
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=        2048, size=      260096, type=83
/dev/sda2 : start=      262144, size=      262144, type=82
/dev/sda3 : start=      524288, size=      524288, type=83

The dump is an sfdisk script. You can archive it, diff it after changes, and feed it back to recreate the same layout.

Verify the backup before you need it

A backup you never checked is easy to distrust during an incident. Read the file first:

cat sda-partitions.dump

Then compare it to a fresh dump from the live disk:

sudo sfdisk --dump /dev/sda

When you want a strict equality check, diff both streams:

diff <(sudo sfdisk --dump /dev/sda) sda-partitions.dump

No output from diff means the files match. Store the dump off the disk it describes: another disk, a configuration repository, or backup storage. A partition table backup kept only on /dev/sda3 does not help when the table on /dev/sda is wrong.

Restore a partition table from the dump

Restoring writes new partition metadata to the target disk. Double-check the device name before you run anything:

sudo sfdisk /dev/sda < sda-partitions.dump

Sample output during restore:

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

Disk /dev/sda: 512 MiB, 536870912 bytes, 1048576 sectors
...
>>> Created a new GPT disklabel (GUID: 59C4E59B-0C92-4D29-9E01-6D399F290C6F).
/dev/sda1: Created a new partition 1 of type 'Linux filesystem' and of size 127 MiB.
...
The partition table has been altered.

Confirm the kernel sees the restored layout:

sudo fdisk -l /dev/sda

fdisk -l confirms sector ranges from the table; lsblk shows whether partition device nodes appeared:

lsblk /dev/sda

Safety notes:

• Pointing sfdisk at the wrong disk overwrites that disk's partition metadata.
• Unmount partitions on the target disk before restore when possible. sfdisk refuses some operations when partitions are busy.
• Restoring the partition table does not create or repair filesystems. If the original filesystem data is still present at the restored offsets, verify it first with lsblk -f or blkid and mount or repair it as appropriate. Do not run mkfs on a recovered partition unless you intentionally want to create a new filesystem and overwrite the old filesystem metadata.

If the system will not boot normally, boot from live media or rescue mode, identify the correct block device, and run the same sfdisk /dev/sdX < dump command there. You do not need distribution-specific rescue menus beyond access to the disk and the dump file.

Copy the partition layout to another disk

Cloning layout is a common reason to keep a dump. Export from the source, import on the destination:

sudo sfdisk --dump /dev/sda > layout.dump

The destination must be large enough for every partition end sector in the dump. Then apply the same script:

sudo sfdisk /dev/sdb < layout.dump

Two constraints matter:

1. Capacity. The destination must be large enough for the highest partition end sector in the dump. If the layout does not fit, do not force it onto the smaller disk; resize the layout and filesystems deliberately first.
2. Duplicate identifiers. sfdisk restores GPT partition UUIDs and the disk label ID from the dump. The util-linux manual warns that duplicating a layout onto another disk can produce duplicate UUIDs on one system. If both disks stay attached, tools that key off PARTUUID in fstab UUID and label entries or boot loaders can target the wrong partition.

This copies geometry only, not data blocks. After cloning layout to an empty disk you still create or copy filesystems separately. It is not full disk cloning.

To keep both GPT disks online, assign a new disk ID with sfdisk --disk-id and new partition UUIDs with sfdisk --part-uuid. These commands require the new identifier as an argument when changing it; without an identifier they only print the current value.

Binary backup of GPT or MBR partition-table sectors

sfdisk --dump stores a logical description. sfdisk --backup-pt-sectors copies the raw sectors that hold partition-table metadata:

sudo sfdisk --backup-pt-sectors /dev/sda

On a GPT disk the command reports several files, typically under your home directory:

Backup files:
        PMBR (offset     0, size   512): /root/sfdisk-sda-0x00000000.bak
  GPT Header (offset   512, size   512): /root/sfdisk-sda-0x00000200.bak
 GPT Entries (offset  1024, size 16384): /root/sfdisk-sda-0x00000400.bak
GPT Backup Entries (offset 536854016, size 16384): /root/sfdisk-sda-0x1fffbe00.bak
GPT Backup Header (offset 536870400, size   512): /root/sfdisk-sda-0x1ffffe00.bak

On an MBR disk you usually see a single 512-byte MBR sector backup.

Each .bak file represents one saved partition-table region. The sfdisk(8) manual shows how to restore an individual region with dd, the recorded byte offset, and conv=notrunc. Restoring one GPT header file alone is not the same as restoring every partition-table sector saved by --backup-pt-sectors. Modern util-linux no longer provides sfdisk -I for sector restore; use dd to write the .bak file back to the matching offset.

GPT vs MBR backup differences

MBR (DOS label). Partition entries live in the first sector's partition table area, with a small boot code region before them. A text dump captures start, size, and type for each slot.

GPT. Layout metadata is spread across:

• Protective MBR in sector 0
• Primary GPT header and partition entry array near the start
• Backup partition entries and backup header near the end of the disk

That is why copying only 64 bytes from the legacy MBR entry region is a poor general backup strategy on modern disks. It ignores GPT headers and backup copies at the end of the device.

Historical note: some older guides used dd to copy bytes 446–509 of sector 0 for MBR partition entries only. That technique does not represent a full GPT layout and should not be your primary method today. Prefer sfdisk --dump for everyday work and --backup-pt-sectors when you need raw sector images.

Common problems

The old sfdisk -R reread option is gone. Use blockdev --rereadpt, partprobe, or partx instead, then verify with lsblk and fdisk -l.

References

• sfdisk(8) — util-linux
• fdisk(8) — util-linux
• Red Hat documentation: GPT disk partitioning

Summary

Backing up a Linux partition table means saving the disk's layout map, not the files inside partitions. sfdisk --dump produces a portable text description for both GPT and MBR disks, and feeding that file back with sfdisk /dev/sdX < dump restores start sectors, sizes, types, and GPT UUIDs. Keep dumps off the disk they describe, verify them with diff while things are healthy, and treat restore as destructive if you aim at the wrong device.

When you copy a layout to another disk, confirm the destination is large enough and plan for duplicate PARTUUID values if both disks stay attached. For raw sector images, especially on GPT where metadata also lives at the end of the disk, sfdisk --backup-pt-sectors complements the text dump. Filesystem creation, file backup, and LVM administration stay separate tasks once the partition table is back in place.