How to backup mbr & gpt partition tables ?



Reaction score: 280
Messages: 1,077

Well, gpart(8) gives you an example how to use the gpart backup for GPT partition scheme. For mbr you can always use dd if=/dev/$disk of=mbr.backup bs=512 count=1.
In MBR, when you use the old style partitions/slices you can use bsdlabel(8).


Well-Known Member

Reaction score: 198
Messages: 424

count=34 will dump both mbr and gpt according to wikipedia


Active Member

Reaction score: 44
Messages: 109

FreeBSD - how to backup and restore MBR record.
If you want to have a dumb copy of MBR - just use dd() as adviced by _martin

Another way is to use fdisk() for backup and restore:
fdisk -p /dev/ada2 > ada2-mbr-backup
fdisk -tv -f ada2-mbr-backup /dev/adaXXX
fdisk -v -f ada2-mbr-backup /dev/adaXXX

If you use FreeBSD partitions - be sure that you have bsdlabel() scheme backup in addition to MBR backup
How to backup and restore bsdlabel:
bsdlabel /dev/adaXsX > adaX-bsdlabel-backup
bsdlabel -R /dev/adaXsX adaX-bsdlabel-backup
Alain De Vos

Alain De Vos


Reaction score: 613
Messages: 2,073

This info is also interesting,
geom disk list | egrep "Sectorsize|Stripesize|Name"
Like you said. For mbr
fdisk -p
For gpt
gpart backup


Son of Beastie

Reaction score: 2,301
Messages: 3,212

First part of the answer: For GPT, it's done automatically for you: A second copy of the GPT partition table is stored on the last few blocks of the disks, and BIOSes and OSes know how to restore from the backup copy. Matter-of-fact, some BIOSes are too good at it, and if they think the primary copy (at the beginning) has been "destroyed", they will automatically and blindly restore from the backup ... without checking that perhaps the user wants to use the whole disk without partition table!

Second part of the answer: There are many ways to take a backup of the partition table, many described above. One particularly nice one: "gpart list adaX" and "gpart show -l adaX", and save the output into a text file, and your backup program will back that text file up. (You need both versions, the first one has all the details, the second one has the partition name string.) The advantage of this over "gpart backup" is: it has all the details.

But the real question is: Doing a backup is meaningless unless you have a plan to restore it. Let's assume that your disk was completely destroyed, for example stepped on by an elephant (happens all the time). You buy a new blank disk, find the backup copy of the MBR or GPT or bsdlabel, and restore it with some combination of hand-typing the equivalent commands to recreate the partitions (which will have slightly different GUIDs!) or restoring the label some "gpart restore" style program. Now what? You have actually accomplished nothing useful, since the rest of the disk is still blank. So if you really want your data back, you need to run some restore program to get the data back from your backup mechanism. I have no idea what your backup and restore mechanism is, but you need to think through how you will integrate restoring the partition table into your whole restore workflow.

Here is what I really do: When I do sys admin tasks, I keep logbooks, which contain clear text entries of what I did when. It might for example say for some day in 2016: "Got the new 3TB disk in the mail, formatted it in GPT with one UFS file system partition size 200GB for use by hippo, and all the rest into one giant ZFS partition which will be added to the RAID-6 group for rhino." If I had to replace the disk after the unfortunate incident with the elephant, I would probably order a new disk (today that would probably be a 10TB), decide how to format it (probably 400gig for hippo, and rhino has grown a lot), and then do my backup file-by-file. So the actual backup of the GPT partition isn't really used, other than as a general guide for how to format the new one.

On the other hand, if you hope to restore backups by doing a "dd" copy from the old to the new disk, then having a bit-accurate backup of the GPT is a good starting point.