119

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.

Lauritz V. Thaulow
  • 3,519

5 Answers5

134

You can use sfdisk for this task even in GPT partitioned disks*.

Save:

sfdisk -d /dev/sdX > part_table

Restore keeping the same disk & partition IDs**:

sfdisk /dev/sdX < part_table

Restore generating new disk & partition IDs**:

grep -v ^label-id part_table | sed -e 's/, *uuid=[0-9A-F-]*//' | sfdisk /dev/sdY

Notes

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

**: by default sfdisk will copy the disk and partition IDs unchanged, rather than generating new ones. So the new disk will be 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 delete the references to partitions ids (, uuid=...) and the reference to the disk id (label-id: ...) from the dump .

ndemou
  • 2,809
Petr Uzel
  • 7,257
  • Exactly what I was looking for, thank you! However, the man page says sfdisk is "not designed for large partitions", but does not specify any further what it means by "large". What specific limits does this impose? Will sfdisk tell me if it can't cope? – Lauritz V. Thaulow May 11 '11 at 08:48
  • 1
    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 09:05
  • 3
    sfdisk doesn't work with large volumes or support GPT. – dhchdhd May 11 '11 at 09:11
  • 1
    @Barry and when you say "large", you're referring to the 2TB limit @Petr is talking about? – Lauritz V. Thaulow May 11 '11 at 09:18
  • 7
    The correct way is:sudo parted /dev/sda -lm > sda.parted – dhchdhd Aug 12 '11 at 08:17
  • 1
    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
  • I use this in one shot :

    sudo sfdisk -L -d /dev/disk/bypid/$SOURCE | sudo sfdisk -L /dev/disk/by-id/$TARGET

    Use disk-ids if you're a dizzy head.

     – rzr Nov 19 '15 at 23:52
  • @rzr: -L is deprecated, but still accepted (as a no-op?) for backward compatibility. But yes, sfdisk --dump | sfdisk appears to be all you need. Also, nobody mentioned yet that sfdisk does support GPT partitions, since util-linux 2.26, where it was re-written from scratch on top of libfdisk. – Peter Cordes Feb 27 '16 at 02:53
  • Looks like you can't do this on the kernel device. – Sridhar Sarnobat Oct 28 '21 at 03:25
68

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:

disk=/dev/sda

# 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

Given

source=/dev/sda
dest=/dev/sdb

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:

# Save GPT 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

The last 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.

mivk
  • 3,596
  • 13
    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 09:56
  • Is there any risk to the existing data on the disks and subsequent partitions when you move the partition table and then randomize the GUID of the disks and partitions as you describe above? Thanks! – EngBIRD Aug 22 '16 at 00:36
  • @EngBIRD: As long as you don't mixup $source and $dest, there cannot be risk to data, since there is no data on the destination. You only copy the partition layout, and still need to format and copy the data afterwards. – mivk Aug 22 '16 at 10:00
  • The reason I asked is in fact I'm not starting from a blank disk, I'm swapping two disks around... – EngBIRD Aug 22 '16 at 13:53
  • --load-backup= worked for me unlike --replicate, so that's 2 reasons for me to use it. – Sridhar Sarnobat Oct 28 '21 at 03:35
3

Older but still interesting pyparted and python-lvm bindings.

Update:

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:

BYT;
/dev/sda:12.9GB:scsi:512:512:msdos:VMware Virtual disk;
1:1049kB:12.9GB:12.9GB:::boot, lvm;
user
  • 28,901
dhchdhd
  • 348
  • 17
    How do you restore from the saved sda.parted file to a new disk? – Son of the Wai-Pan Jun 20 '12 at 01:46
  • 6
    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 08 '15 at 12:31
  • Apparently at this time, there is no good answer: https://serverfault.com/questions/709582/how-to-restore-a-saved-partition-table-to-another-disk-with-parted – Otheus May 30 '19 at 09:57
3

Short for GPT disk partition table (required for >2TB disk size):

Check the source disk partition table (print)

sgdisk -p /dev/sda
Disk /dev/sda: 31251759104 sectors, 14.6 TiB
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 9EE86B93-3BA5-3C48-A6C5-111122223333
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 31251759070
Partitions will be aligned on 2048-sector boundaries
Total free space is 33 sectors (16.5 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048     15626993630   7.3 TiB     8E00

   2     15626993664     31251759070   7.3 TiB     8E00

clone GPT disk SDA partition table to new disk SDB (Replica)

sgdisk /dev/sda -R /dev/sdb
The operation has completed successfully.

Check the replica disk partition table (print)

sgdisk -p /dev/sdb
Disk /dev/sda: 31251759104 sectors, 14.6 TiB
Sector size (logical/physical): 512/4096 bytes
**Disk identifier (GUID)**: 9EE86B93-3BA5-3C48-A6C5-111122223333
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 31251759070
Partitions will be aligned on 2048-sector boundaries
Total free space is 33 sectors (16.5 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048     15626993630   7.3 TiB     8E00

   2     15626993664     31251759070   7.3 TiB     8E00

Note that Disk identifier (GUID) is the same, thus in most cases requires reGeneration to new, random one:

sgdisk -G /dev/sdb
The operation has completed successfully.

Check the replica disk partition table (print) again

sgdisk -p /dev/sdb
Disk /dev/sda: 31251759104 sectors, 14.6 TiB
Sector size (logical/physical): 512/4096 bytes
**Disk identifier (GUID)**: 9EE86B93-3BA5-3C48-A6C5-925AB6C8E86B
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 31251759070
Partitions will be aligned on 2048-sector boundaries
Total free space is 33 sectors (16.5 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048     15626993630   7.3 TiB     8E00

   2     15626993664     31251759070   7.3 TiB     8E00

Note that Disk identifier (GUID) is now unique.

Arunas Bart
  • 811
  • 6
  • 13
2

Modern sfdisk appears to work for both mbr and gpt partition tables.

My preferred method is:

sfdisk -d /dev/nvme0n1 | sfdisk /dev/nvme1n1

Where /dev/nvme0n1 is the source disk and /dev/nvme1n1 is the target disk.

Owen DeLong
  • 83
  • 1
    Perhaps since we already have (several) sfdisk answers, we could suggest an edit to one of them that points out this pipeline functionality? – Jeff Schaller May 21 '20 at 17:03