Repairing GPT Disks

by Rod Smith, [email protected]

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

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:

On gdisk's main menu, you'll find the b option, which saves partition data to a disk file. You can also use sgdisk for this task, as in sgdisk -b sda-backup.gpt /dev/sda to save a backup of /dev/sda to the file sda-backup.gpt; or use the Backup option in cgdisk. Using any of these programs, the data saved is the protective MBR, the main header, the backup header, and one copy of the partition table. These items are stored in a binary file in this order. You should back up your partition table and keep this file on another computer or on a removable medium (USB flash drive, optical disc, etc.). You can then recover from very serious corruption by loading this file back (using the l option on the recovery & transformation menu) and saving your changes back to the disk's partition table (using w).
You can display your partition summary information using the p command, and if you want this level of detail, use the i command to view the detailed information on each partition. You can then cut-and-paste this information to a text file and save it. This method results in more tedious recovery than the first, since you'll need to manually re-create your partitions (including their GUID codes, if this detail is important). This method has the advantage, though, that you can print the data on paper for safekeeping with other hardcopy information on your computer.

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:

User error — You might, when using GPT fdisk or some other disk partitioning tool, accidentally delete a partition, set the wrong partition type code, or even wipe out an entire partition table. Such problems can be hard to fix, since the partitioning tool will duplicate your error on both the main and the backup data structures. On rare occasion, you might be able to recover information from a hybrid MBR, if your error involved a partition that was hybridized. Use the o option on gdisk's experts' menu to obtain the start sector and length of the affected partition. You can then re-create the partition, entering those values.
GPT utility errors — GPT utilities can contain bugs, and these bugs can result in any manner of partition table problems. Thankfully, bugs that render a disk completely useless are rare. As noted on other pages of this document, though, very old versions of GNU Parted and its relatives are known to set incorrect GPT type codes for FAT, NTFS, and bootable partitions. You can use GPT fdisk's t option to correct this problem.
MBR/GPT mismatches — The MBR and GPT can become mismatched in various ways, such as using a GPT-unaware disk utility on a GPT disk or editing GPT partitions on a hybrid disk. GPT fdisk detects some of these problems when it runs, and gives you the option of how to proceed. Typically, you'll want to use the MBR data or the GPT data, discarding the other type of data. If you need to somehow integrate the two, I recommend you back up the data and write down the start and end points of the relevant partitions so you can re-create them.
GPT disk re-used as MBR — This is a special case of the preceding problem. If you create GPT partitions on a disk and then decide to use the disk as an MBR-only disk, you can end up with mismatched MBR and GPT data structures. This situation can be confusing, and in principle it could cause some utilities to cause further damage or to refuse to work. In this case, the z option on GPT fdisk's experts' menu may be helpful; it wipes out the GPT data structures, leaving the MBR untouched. You should use this option with caution, though; if the disk really is a valid MBR disk, this option could conceivably damage the first or last MBR partition!
Overwritten GPT main header or table — Various disk utilities have been written to store data in the unused (on true MBR disks) area between the MBR and the start of the first partition. Such utilities, if run on a GPT disk, might overwrite some or all of the GPT main header or partition table. You can use the b and c options on gdisk's experts' menu to have the program use the backup header and partition table, respectively, thus recovering from this problem.
Disk corruption — Power failures at bad times, bugs in software, or other problems can cause any of the five main GPT data structures (protective MBR, main GPT header, main GPT table, backup GPT table, and backup GPT header) to be damaged. GPT fdisk checks for such damage when it starts, and the verify (v) option also checks for such problems. Recovery procedures are described later.
Misplaced data — If you use a hardware RAID array and add a disk to it, the backup data structures will no longer be at the end of the disk. Likewise if you back up your GPT data to a disk file and then restore that backup to a larger disk, or use some disk-duplication techniques to copy one disk's contents to another. In any of these cases, the e option on the recovery & transformation menu will move the backup data structures to their correct location.

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:

The first caution ("after loading partitions, the CRC doesn't check out!") is a generic heads-up that gdisk has detected a CRC mis-match somewhere.
The warning ("main partition table CRC mismatch...") indicates that GPT fdisk detected and automatically corrected a problem with the main partition table.
Because a problem was detected, the program displays a summary of the health of the four CRC-protected GPT data structures. In this example, both headers are OK, as is the backup partition table; but the main partition table is identified as containing an ERROR.
The partition table scan, which is shown by gdisk (but not sgdisk) even on healthy disks, indicates that the GPT data structures were damaged.
The caution surrounded by asterisks is intended to grab your attention. Whenever a disk error is found, you should be alert to peculiar program operation, missing partitions, or other oddities; and you should perform at least minimal checks and verification of the data. At a minimum, I recommend viewing your partition definitions with the p command and verifying the disk with the v command.

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:

The l option on the recovery & transformation menu loads a GPT backup file (created with the b option on the main menu). This is the preferred recovery method if a backup file exists.
The o option on the main menu causes GPT fdisk to create new GPT data structures (headers, partition tables, and MBR) in memory. If your disk's data structures are very badly damaged, using this option first might enable you to load one undamaged partition table to recover your partitions.
The b and d options on the recovery & transformation menu enable you to load the backup and main headers, respectively. These options both load the specified header from disk and rebuild the other header using the one that was just loaded. The GPT headers specify the location of the partition tables on the disk, as well as of the other header, the disk's GUID, and so on. In a recovery situation, these options may not be very useful; GPT fdisk should automatically use an intact header if it can find one. If both headers are damaged, you may be better off rebuilding a new one.
The c and e options on the recovery & transformation menu load the backup and main partition table, respectively. If GPT fdisk loaded a damaged partition table, you can use one of these options to load the other, in case it's undamaged. If the program didn't load any GPT partitions, these options could still be useful, particularly after using the 'o' option on the main menu; it's conceivable that the headers were both damaged, but enough of one or both partition tables survive to reconstruct your disk.
The f option on the recovery & transformation menu loads the MBR and generates a fresh GPT from it. This option can be useful if GPT fdisk mistakenly interpreted an MBR disk as a GPT disk, or if the GPT structures on a hybrid MBR disk were very badly damaged but the MBR definitions remain intact.
The e option on the experts' menu relocates the backup data structures to the end of the disk. This option can be useful in some recovery situations because, if the headers are damaged, GPT fdisk will become confused about where the backup data structures should reside, and as a result an attempt to write the data (using w) will fail. The e option causes the program to recompute this information. This option is also useful if you've resized a hardware RAID array or done a low-level copy of one disk's contents to another one of another size; in both these cases, the backup data structures will no longer reside at the end of the disk, so they should be relocated.
The v option verifies the disk structures. This option displays information on problems the program has identified. Sometimes it reports old problems or problems that will be corrected when you write the data to disk, though, so the report may be overly pessimistic. The v option automatically corrects few problems; it just reports them. This is by design; the problems that are easily solved automatically are handled when GPT fdisk first loads GPT data. Furthermore, although many problems in isolation have obvious solutions, the many possible combinations of different problems pose logical challenges that are best handled on a case-by-case basis by a knowledgeable user. Therefore, the v option presents suggested remedies for many problems, but it doesn't implement them automatically. This way, you can decide which remedy to attempt, should you encounter multiple problems with multiple possible fixes.

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

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

Return to my main web page.