Repairing GPT Disks

by Rod Smith,

Last Web page update: 4/18/2022, referencing GPT fdisk version 1.0.9

This Web page, and the associated software, is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find GPT fdisk or this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!

Donate $1.00 Donate $2.50 Donate $5.00 Donate $10.00 Donate $20.00 Donate another value
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal

Note: This page is part of the documentation for my GPT fdisk program.

GPT was designed with improved robustness in mind compared to the older MBR partition table; as noted in What's a GPT?, GPT includes stored CRC values to help utilities spot problems and redundancy to help recover from them. Neither of these features makes GPT completely immune to errors, though; they just help utilities to detect and recover from those problems.

An Ounce of Prevention

Before you get into trouble, it's worth taking preventive measures: Back up your partition tables! You can do this in either of two ways, and preferably both:

If you take the simple precaution of backing up your GPT data, and keeping this backup current with any changes you make, you should find data recovery much easier.

If your disk is already damaged, performing a gdisk binary backup is a wise precaution before you begin repairing the disk. In the event that your repair attempts make matters worse, you may be able to recover the disk to its damaged state by restoring the backup; however, be aware that GPT fdisk's backup function saves the in-memory representation of the on-disk structures, and the program performs some minimal interpretation in the act of loading the data. Therefore, a backup of a corrupt partition table, when restored, might not exactly replicate the original corrupt state; it could be even worse!

Things that Can Go Wrong

As described in detail on the What's a GPT? page, GPT disks contain five data structures: the protective MBR, the main GPT header, the main partition table, the backup partition table, and the backup GPT header. Any or all of these data structures can become damaged. Although recovery from some problems is fairly simple, other problems may be impossible to fix.

Any or all of the five GPT data structures can become damaged. The easiest problems to repair without a backup are those that involve just one data structure, or at most two that aren't of the same type. Because the MBR is basically just a placeholder, its loss isn't a big deal, although loss of a hybrid MBR will require some slight recovery effort.

GPT data structures can be damaged in several ways:

Semi-Automated Recovery

When GPT fdisk starts, it attempts to read the various GPT data structures. In doing so, the program checks the CRC values stored in the main and backup headers, and it performs various other sanity checks. If GPT fdisk detects a problem, it will notify you, and if a fix is obvious, it will implement it automatically. For instance, consider what happens when GPT fdisk discovers that the main partition table's CRC doesn't match that stored in the main header:

# gdisk /dev/sdf
GPT fdisk (gdisk) version 1.0.9

Caution! After loading partitions, the CRC doesn't check out!
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: OK
Main partition table: ERROR
Backup partition table: OK

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.

Note: Details of what problems are detected vary from one version to another. Version 0.6.2 substantially improved GPT fdisk's reporting and automatic correction of GPT errors.

This example shows five sets of diagnostic messages:

To create this example, I used dd to erase the main partition table. In this example, I was able to use GPT fdisk normally from this point on, despite the cautions and warnings; however, as a general rule, you should pay attention to such warnings.

In some cases, GPT fdisk won't be able to decide what to do when you launch it on a damaged disk. For instance, the software might detect valid GPT data structures and a valid MBR that doesn't include an EFI protective partition. In such cases, gdisk prompts you for which of two or more things to do, such as use the MBR or GPT data structures. In most cases you can use the advanced recovery options to change your choice after you've made it.

Manual Recovery Procedures

In some cases, GPT fdisk won't be able to automatically recover. Several recovery options, most of them on the recovery & transformation menu, can help you recover your partitions, provided at least one valid partition table exists on the disk. You can see the available options by typing ? at the recovery & transformation menu's prompt:

Command (? for help): r

recovery/transformation command (? for help): ?
b	use backup GPT header (rebuilding main)
c	load backup partition table from disk (rebuilding main)
d	use main GPT header (rebuilding backup)
e	load main partition table from disk (rebuilding backup)
f	load MBR and build fresh GPT from it
g	convert GPT into MBR and exit
h	make hybrid MBR
i	show detailed information on a partition
l	load partition data from a backup file
m	return to main menu
o	print protective MBR data
p	print the partition table
q	quit without saving changes
t	transform BSD disklabel partition
v	verify disk
w	write table to disk and exit
x	extra functionality (experts only)
?	print this menu

Highlights of these options include:

If a verify (v) procedure produces a recommendation of taking just one action, such as loading the backup header, then that's probably a good choice. If the program produces competing recommendations, though, your task is harder. One approach is to take the least radical road. For instance, you might relocate the backup data (using e on the experts' menu) rather than load a header. Another approach, particularly if you run into massive corruption of the headers, is to use the o option on the main menu to build a new set of GPT data structures and then load your old partition table using the c or e option on the recovery & transformation menu. If the original disk used an unusual partition table size, though, you'll need to resize your in-memory table before you can successfully load the table from disk.

In all cases, you should exercise extreme caution when performing data recovery. You can experiment with all of the options just described (except for w); none of the data-recovery tools causes immediate writes to the disk. The w option, though, overwrites all your GPT data structures, so if you aren't sure you've recovered your partitions, you should not employ the w option. The z option on the experts' menu is also very dangerous; this option destroys all GPT (and optionally MBR) data structures and then exits.

Going Further

In writing GPT fdisk, I've attempted to anticipate various types of data corruption that might occur on GPT disks. A few individuals have reported real-world problems, as well. I cannot test every possible problem, though, and so it's possible that a particular type of disk error will cause GPT fdisk to misbehave in strange ways or even make the problem worse, particularly if you use the w option to save changes you make.

If your disk contains mission-critical data, I urge you to contact data-recovery specialists rather than poke around with GPT fdisk or any other data recovery software. Although such specialists charge a great deal of money, they have the expertise needed to make full recovery of your data more likely.

If hiring a data-recovery specialist is out of the question, making a complete backup of the problem disk can help ensure that you won't make matters worse. You can use the dd command to do this job:

# dd if=/dev/sda of=/dev/sdb status=progress

Be sure to get the if and of parameters right; if you reverse them, you'll end up overwriting the disk you want to restore! This example backs up /dev/sda to /dev/sdb. The latter must be as large as or larger than the former disk, and the backup will take a long time — probably measured in the hours. (The status=progress option produces a progress indicator so you can judge how far the backup has proceeded; but this option is not supported in older versions of dd.) Such a backup will be a complete low-level backup of the original disk, so that if you damage the original during your tests, you can at least restore the backup. Note that if the backup disk is larger than the source, even by a single sector, the GPT backup data structures will be misplaced on the backup disk. This can make GPT data recovery harder, so you may need to work on the original disk rather than the backup.

Go on to "Obtaining GPT fdisk"

Return to "GPT fdisk" main page

copyright © 2009–2022 by Roderick W. Smith

If you have problems with or comments about this web page, please e-mail me at Thanks.

Return to my main web page.