Repairing GPT Disks
Last update: 6/26/2011, GPT fdisk version 0.7.2
I'm a technical writer and consultant specializing in Linux technologies. 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 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. Using either method, 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, floppy disk, CD-R,
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 GPT fdisk'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, 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
- 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
- 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
- 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. In either case, the 'e'
option on the recovery & transformation menu will move the backup
data structures to their correct location.
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/sdc
GPT fdisk (gdisk) version 0.7.2
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!
Partition table scan:
BSD: not present
APM: not present
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 three diagnostic messages:
- The warning ("main partition table CRC mismatch...") indicates that
GPT fdisk detected and automatically corrected a problem.
- 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 caution; 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). 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
- 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; in this case, 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.
Caution: Software Under Construction
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
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
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. 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
Return to my main web page.