Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to take a backup of the whole partition layout of a hard drive, including logical drives, so that I can restore that layout to another disk. I do not want to copy the contents of the partitions, only the layout. For the primary and extended partitions, it's easy:

dd if=/dev/sda of=partitiontable.bin bs=1 skip=446 count=64 # backup
dd if=partitiontable.bin of=/dev/sda bs=1 seek=446 count=64 # restore

But when it comes to the layout of the logical partitions, I wonder if there exists among the standard tools a similar way of saving the layout? I guess the main problem is finding the offsets to the locations of the EBRs, because with that, dd will do the rest. Keep in mind I need to be able to put everything back to a (possibly) blank disk and thereby restore the same layout. Using partitioning tools like fdisk or parted is fine, but I must be able to automate their use (scripting) and they should not depend on any X-related packages -- command line only.

My backup plan is doing it manually in a little python script using the struct module, but I rather hoped there was an easier way.

share|improve this question
up vote 52 down vote accepted

You can use sfdisk for this task.


sfdisk -d /dev/sda > part_table


sfdisk /dev/sda < part_table

For GPT partition tables, this requires sfdisk from util-linux 2.26 or later. It was re-written from scratch on top of libfdisk.

This copies the UUIDs unchanged, rather than generating new ones. So the new disk is a clone of the original, not just another disk with the same layout. Note that Linux's /dev/disk/by-uuid/ looks at filesystem UUIDs, though, not UUIDs in the partition table. sfdisk will generate new UUIDs if you edit out the UUIDs from the dump (per-partition and the UUID for the partition table itself near the start of the file).

share|improve this answer
I don't know for sure, but the only limit that comes to my mind is the 2TB size limit for partition imposed by msdos partition table scheme. To overcome this limit, one can use GPT instead, but AFAIK sfdisk can not work with GPT. I don't know if there is any other limit nor if sfdisk will report if it can't cope. – Petr Uzel May 11 '11 at 9:05
sfdisk doesn't work with large volumes or support GPT. – Barry May 11 '11 at 9:11
@Barry and when you say "large", you're referring to the 2TB limit @Petr is talking about? – Lauritz V. Thaulow May 11 '11 at 9:18
The correct way is:sudo parted /dev/sda -lm > sda.parted – Barry Aug 12 '11 at 8:17
Sometimes it is useful, to ignore DOS only problems, to add the -L or --linux option: sfdisk -L /dev/sda < part_table – Diego Jul 15 '14 at 10:17

It depends if your source disk uses an MBR (aka "dos" or "msdos") or a GPT (aka "GUID") partition table.

Disks over 2 TB cannot use MBR, so they are GPT.

Disks under 2 TB can use both, so you will have to first find out which it is.

Assuming you are on Linux, use either of these commands to find out which partition table your source disk uses:


# Always available, but old versions may not recognize gpt
fdisk -l $disk | grep type

# `apt-get install gdisk` or equivalent on non-Debian systems
gdisk -l $disk | grep -A4 'scan'

# `apt-get install parted`
parted $disk print | grep Table



For MBR disks

use sfdisk as suggested by Petr Uzel's answer, or this variant:

# Save MBR disks
sfdisk -d $source > /partitions-backup-$(basename $source).sfdisk
sfdisk -d $dest   > /partitions-backup-$(basename $dest).sfdisk

# Copy $source layout to $dest
sfdisk -d $source | sfdisk $dest

For GPT disks

The correct answer was given here and here by Kris Harper.

You need GPT fdisk. Look at the download page or run sudo apt-get install gdisk.

Then use the sgdisk command like so

sgdisk -R=/dev/sdb /dev/sda
sgdisk -G /dev/sdb

The first command copies the partition table of sda to sdb (be careful not to mix these up). The second command randomizes the GUID on the disk and all the partitions. This is only necessary if the disks are to be used in the same machine, otherwise it's unnecessary.

Or this alternative:

# Save MBR disks
sgdisk --backup=/partitions-backup-$(basename $source).sgdisk $source
sgdisk --backup=/partitions-backup-$(basename $dest).sgdisk $dest

# Copy $source layout to $dest and regenerate GUIDs
sgdisk --replicate=$dest $source
sgdisk -G $dest
share|improve this answer
I'm always scared I'll mix the two parameters, so a good trick is to use --backup=File to export a partition table from the source drive and --load-backup=File to restore in on the destination drive. – zidarsk8 Jul 24 '14 at 9:56

Older but still interesting pyparted and python-lvm bindings.


The previous was posted because the above does not work in many modern situations per the sfdisk man page.

sfdisk doesn't understand GUID Partition Table (GPT) and it is not designed for large partitions. In particular case use more advanced GNU parted(8).

This command however supports >2 TB partitions and LVM.

# parted -ms /dev/sda print > sda.parted

Sample output:

/dev/sda:12.9GB:scsi:512:512:msdos:VMware Virtual disk;
1:1049kB:12.9GB:12.9GB:::boot, lvm;
share|improve this answer
How do you restore from the saved sda.parted file to a new disk? – Avery Chan Jun 20 '12 at 1:46
This answer is useless because the question was about copying the partition layout to a new drive. The answer is just about dumping. How to import ? Please improve. – itsafire Oct 8 '15 at 12:31

The wipefs utility is included in the util-linux package and is designed for this. It's not a standard utility on anything but linux systems, though.

man wipefs


wipefs [-ahnpqtV] [-o offset] device...


wipefs can erase filesystem, raid or partition-table signatures (magic strings) from the specified device to make the signatures invisible for libblkid. wipefs does not erase the filesystem itself nor any other data from the device. When used without any options, wipefs lists all visible filesystems and the offsets of their basic signatures.

wipefs calls the BLKRRPART ioctl when it has erased a partition-table signature to inform the kernel about the change.

Note that some filesystems and some partition tables store more magic strings on the device. The wipefs command lists only the first offset where a magic string has been detected. The device is not scanned for additional magic strings for the same filesystem. It is possible that after a wipefs -o offset the same filesystem or partition table will still be visible because of another magic string on another offset.

When option -a is used, all magic strings that are visible for libblkid are erased.

Note that by default wipefs does not erase nested partition tables on nonwhole disk devices. For this the option --force is required.


 wipefs --all --backup /dev/sdb

Erases all signatures from the device /dev/sdb and creates a signature backup file ~/wipefs-sdb-<offset>.bak for each signature.

 dd  if=~/wipefs-sdb-0x00000438.bak  of=/dev/sdb  seek=$((0x00000438)) bs=1 conv=notrunc
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.