GPT (GUID Partition Table)

Intel began developing GPT in the late 1990s as part of what became the Unified Extensible Firmware Interface (UEFI), a replacement for the aging BIOS firmware standard. GPT was first published in 2002 with EFI 1.0 and has been a standard part of every UEFI specification since. The current version is described in chapter 5 of UEFI 2.11.¹

The motivation was straightforward: MBR was a 1983 design that hadn’t aged well. Its 32-bit Logical Block Addresses limited disks to 2 TB. Its 4-primary-partition limit was an arbitrary side effect of the partition table fitting in a single 512-byte sector. Its lack of any checksum or redundancy meant a single damaged sector could destroy the partition table irrecoverably. By 2002, multi-terabyte disks were on the horizon and the industry needed something better.

GPT solves all three problems and adds new capabilities. Logical Block Addresses are 64-bit, supporting disks up to 9.4 ZB (zettabytes). The partition table holds 128 entries by default and can be expanded if needed. Both the header and the partition array carry CRC32 checksums, so corruption is detected with certainty rather than guessed at. And the entire partition table is stored twice: a primary copy at the start of the disk and a backup at the end. The backup is GPT’s defining recovery feature.

Logical Block Addressing (LBA) terminology

GPT uses LBA (Logical Block Addressing) terminology throughout, where LBA 0 is the first logical block on the disk, LBA 1 is the second, and so on. On traditional 512-byte-sector disks, LBA 0 is sector 0, LBA 1 is sector 1, etc. On 4K-native (“Advanced Format”) disks where logical blocks are 4096 bytes, the mapping is different but the same concepts apply. Throughout this entry, “sector” and “LBA” can be read as roughly interchangeable for most purposes.

The 128-bit GUID

The “GUID” in GPT stands for Globally Unique Identifier: a 128-bit number (16 bytes) intended to be statistically unique without coordination. The same concept Microsoft calls UUID in other contexts. GPT uses GUIDs for two purposes: the disk itself has a unique Disk GUID, and each partition has both a Partition Type GUID (identifying what kind of partition it is, like EFI System Partition, Linux filesystem, or Windows basic data) and a Partition Unique GUID (uniquely identifying that specific partition).²

Why this matters in practice: partitions can be referenced by GUID rather than by drive letter or position on disk. UEFI bootloaders like systemd-boot and GRUB can specify “boot the partition with GUID X” instead of “boot the third partition on the first disk.” This makes boot configurations portable when disks are reorganized.

CRC32 checksums on everything

GPT is the first widely-deployed partition scheme to include integrity checksums. Both the GPT Header and the Partition Entry Array have CRC32 checksums stored in the header. When the OS reads the partition table, it computes the CRC32 over the actual data and compares it to the stored value. A mismatch means the data has been corrupted and shouldn’t be trusted.³

This is what enables the redundancy to actually work. Without checksums, the OS would have no way to know which copy of the partition table is correct when primary and backup disagree; it would have to guess. With checksums, the OS knows: Main partition table CRC mismatch! Loaded backup partition table instead, as gdisk reports in real-world recovery scenarios.⁴

Partition type GUIDs

Each partition’s type GUID tells the OS what kind of partition it is. Some common ones:

• EFI System Partition (ESP): C12A7328-F81F-11D2-BA4B-00A0C93EC93B: holds the bootloader on UEFI systems.
• Microsoft Reserved Partition (MSR): E3C9E316-0B5C-4DB8-817D-F92DF00215AE: reserved space on Windows GPT disks.
• Microsoft Basic Data: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7: used for NTFS, FAT32, exFAT data partitions on Windows.
• Linux filesystem: 0FC63DAF-8483-4772-8E79-3D69D8477DE4: generic Linux partition (defined jointly by GPT fdisk and GNU Parted developers in the 2010s after Linux’s lack of a dedicated GUID caused dual-boot issues).
• Linux swap: 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F: Linux swap partition.
• Apple APFS: 7C3457EF-0000-11AA-AA11-00306543ECAC: APFS container on Apple disks.
• Apple HFS+: 48465300-0000-11AA-AA11-00306543ECAC: legacy Apple HFS+ partition.

RFC 4122 governs GUID generation, and there’s no central registry. Anyone can define a partition type by generating a GUID and publishing what it means. The collision probability is negligible.

GPT’s defining redundancy comes from having five distinct structures spread across the disk. Knowing what each one does is essential for understanding GPT recovery; recovery tools like gdisk specifically describe their state (“Main header: OK / Backup header: ERROR”) in these terms.⁵

1. Protective MBR (LBA 0)

The first sector of a GPT disk holds a fake MBR. It contains a single MBR-style partition entry of type 0xEE (“EFI GPT”) that claims the entire disk. Tools that don’t understand GPT see this and conclude the disk is fully partitioned, so they don’t try to write to it and accidentally corrupt the GPT structures. The Protective MBR is required for bootable GPT disks; data-only GPT disks technically don’t need one but virtually all have one for safety.

This is purely a compatibility hack, not part of the actual partition table. The Protective MBR’s partition entry doesn’t describe any real partition; it’s a “DO NOT TOUCH” sign for legacy tools.

2. Primary GPT Header (LBA 1)

The 92-byte structure that defines the GPT layout. Holds the magic signature EFI PART, a revision number, the location of the partition entry array (typically LBA 2), the location of the backup header (typically the last LBA), the disk’s unique GUID, and the CRC32 of the header itself plus the CRC32 of the partition entry array. The header is read first when the OS examines the disk; everything else is found via pointers from the header.

3. Primary Partition Entry Array (LBAs 2-33 by default)

The actual list of partitions. Default size is 128 entries × 128 bytes = 16,384 bytes, which fills 32 sectors on a 512-byte-sector disk. Each entry holds the partition type GUID, the unique partition GUID, the start LBA, the end LBA, attribute flags, and a 36-character UTF-16 partition name. Entries that aren’t in use have all zeros for the type GUID. The CRC32 of the entire array is stored in the header.

4. Backup Partition Entry Array (near end of disk)

An exact copy of the primary partition entry array, located near the end of the disk just before the backup header. When the OS or recovery tools detect that the primary array is corrupt (CRC mismatch), they fall back to this backup. This is the structural redundancy that makes GPT recovery so reliable.

5. Backup GPT Header (last LBA)

An exact copy of the primary GPT header, stored in the very last logical block of the disk. The backup header’s “My LBA” field correctly identifies its own location at the end of the disk; its “Alternate LBA” field points to the primary header’s location at LBA 1. So the OS can detect inconsistencies by reading both headers and comparing.

Why redundancy at the end of the disk specifically

Putting the backup at the end of the disk seems arbitrary, but it’s deliberate: the most likely failure mode for a partition table is overwriting from the start of the disk. Bootloader installations, MBR-only disk utilities, badly-configured installers, accidental dd if=/dev/zero of=/dev/sdX operations. All these start writing from sector 0 and progress toward higher sectors. The end of the disk is far away from this damage and likely to survive.

The trade-off: if the disk is imaged to a smaller destination (cloning a 1 TB drive to 500 GB), the backup at the source’s end-of-disk now lies beyond the destination’s end-of-disk. The destination will have an invalid backup. Modern imaging tools warn about this; older tools silently produce corrupt clones.

The Partition entry covers the high-level differences. Here’s the detailed comparison from a recovery-relevant perspective.⁶

When MBR still makes sense

Use MBR for: legacy systems with BIOS-only firmware that cannot boot from GPT; bootable USB sticks intended to start old Windows or Linux installers on legacy systems; specific embedded systems with hard MBR requirements; some specialized recovery USBs that need to work universally. These cases are increasingly rare in 2026; almost every system built since 2012 supports UEFI booting from GPT.

Use GPT for everything else. New Windows installations default to GPT. New macOS installations are GPT-only on Apple Silicon. New Linux installations default to GPT for both system and data disks. Any disk larger than 2 TB must use GPT. Any new USB external drive should generally use GPT for the redundancy and integrity advantages, unless it specifically needs to boot legacy systems.

GPT corruption falls into a small number of recognizable patterns, each with its own recovery approach. The CRC32 checksums make corruption easy to detect; the redundancy makes most corruption recoverable. The remaining recovery cases are the ones where both primary and backup are damaged.⁷

• Primary GPT header CRC mismatch. The primary header at LBA 1 fails its CRC32 check. The OS or recovery tool detects this immediately and falls back to the backup header at the end of the disk. Recovery is usually a one-step operation: copy the backup header to the primary location.
• Primary partition entry array CRC mismatch. The primary array at LBAs 2-33 fails its CRC32 check, but the primary header is intact. Recovery falls back to the backup array; gdisk reports this as Main partition table: ERROR / Backup partition table: OK.
• Backup GPT header CRC mismatch. The backup at the last LBA is damaged but the primary is intact. gdisk reports Main header: OK / Backup header: ERROR and offers to regenerate the backup from the primary. This is one of the more common scenarios with USB drives that have been cloned with imperfect tools.
• Both primary and backup damaged. The harder scenario. CRC32 mismatches on both copies indicate either severe corruption (both ends of the disk damaged) or a tool that wrote inconsistent metadata. TestDisk’s deep scan can sometimes find the partitions by file system signatures and rebuild the GPT from scratch.
• Protective MBR damage. The fake MBR at LBA 0 is overwritten or modified. The actual GPT may be intact, but tools see what looks like a real MBR pointing at unknown content. Some tools may try to “help” by zeroing the GPT they don’t recognize. gdisk‘s r menu has a recovery option specifically for rebuilding the protective MBR.
• Disk size mismatch. The GPT header records a “Last Usable LBA” and “Alternate LBA” (location of backup header). If the disk is cloned to a different-sized target or if firmware reports a different size than expected, these fields no longer match reality. gdisk reports Disk size is smaller than the main header indicates! Loading secondary header from the last sector of the disk! Common when restoring images.
• Hybrid MBR confusion. A disk has both a valid GPT and a non-protective MBR with real partition entries (used historically by Boot Camp on Intel Macs and a few Linux dual-boot setups). Tools may see the MBR partitions and ignore the GPT, or vice versa. Recovery requires knowing the original layout was a hybrid; most modern tools handle this but consumer recovery utilities often don’t.
• Cloning to smaller target. Imaging a 1 TB disk to a 500 GB destination leaves the destination’s primary GPT pointing to a backup at LBA position 1,953,525,167, far beyond the destination’s last block. The OS reports the disk as “GPT damaged” because the alternate LBA is invalid. Recovery requires regenerating the backup at the actual end of the destination disk.
• Bad sectors at start or end of disk. Physical bad sectors in the GPT regions specifically. Unusual but devastating. Lab-grade recovery via disk imaging with bad-sector-tolerant tools, then reconstruction at the metadata level.

The lines starting with “Main” and “Backup” are gdisk’s status report on each of the four CRC-checked structures (the Protective MBR has no CRC). In this example, the main partition table is bad but everything else is fine; gdisk has automatically loaded the backup into memory. The fix is to use the experts’ menu (option x from the main menu) and then c to load the backup partition table over the main one, then w to write it back to disk.

Warning signs your GPT disk is failing

GPT systems give clearer warnings than MBR ever did, thanks to the checksums. Watch for these in combination:

• “GPT damaged” messages from gdisk, gparted, or Windows Disk Management. CRC mismatches indicate corruption that needs repair before further use.
• “The primary GPT table is corrupt, but the backup appears OK” messages from gparted. Common scenario, easily fixed with gdisk.
• UEFI firmware refusing to boot with messages about partition table errors. The firmware itself runs CRC checks before trying to boot.
• Partitions appearing and disappearing across reboots. Indicates inconsistency between primary and backup, or between GPT and the OS’s cached view.
• Disk shows up with completely unexpected partition layout. Often a sign of GPT damage or hybrid MBR confusion. Don’t write to the disk; image it first and investigate from a copy.
• Windows Disk Management shows the disk as MBR when it should be GPT. Indicates Protective MBR damage where Windows is now reading the bogus MBR data.
• SMART warnings on the underlying disk. Hardware failure threatens GPT integrity. Address the disk before the partition table becomes unrepairable.
• Cloning errors when imaging the disk. Indicates damaged sectors specifically in the GPT regions, which need bad-sector-tolerant imaging tools.

Most GPT disks have a clean Protective MBR, a placeholder that says “stay away, this is GPT.” Some disks, mostly Macs running Boot Camp from before Apple Silicon, have a Hybrid MBR instead: a real MBR with real partition entries that mirror the GPT, allowing the disk to boot both UEFI and legacy BIOS systems. This is a non-standard hack with significant recovery hazards.⁸

When hybrid MBR exists

• Pre-Apple Silicon Macs running Boot Camp. Apple’s Boot Camp Assistant created hybrid MBRs from Mac OS X 10.5 (2007) through the end of Intel Mac support. The Mac side of the disk used GPT; the Windows side appeared in MBR format for legacy compatibility. Apple Silicon Macs (M1+) don’t run Boot Camp at all and therefore don’t create hybrid MBRs.
• Linux dual-boot systems with old BIOS firmware. Some Linux installers used to create hybrid MBRs to work around BIOS systems that couldn’t boot directly from GPT. Increasingly rare since UEFI is universal.
• Some embedded and industrial systems that need to work with both modern UEFI and legacy BIOS firmware on the same disk image.

Why hybrid MBR is hazardous for recovery

The Protective MBR contains type 0xEE and is recognizable as “this is GPT.” Hybrid MBR contains real partition types (0x83 for Linux, 0x07 for NTFS, etc.) that look like a normal MBR layout. Recovery tools that only check the MBR may treat the disk as MBR-only and never look at the GPT, finding only a subset of the actual partitions. Tools that prefer GPT may ignore the hybrid MBR and lose Boot Camp’s Windows partition information.

The recovery rule for hybrid MBR: identify it before doing anything. gdisk on Linux/macOS clearly reports “hybrid MBR” when it sees one. If a disk’s MBR has both type 0xEE and other partition types, it’s a hybrid. Use GPT-aware tools that handle hybrids specifically (gdisk, modern Macs’ Disk Utility, recent versions of TestDisk) rather than older tools that see only one or the other.

Modern alternative: pure GPT with bootloader compatibility

UEFI systems with the Compatibility Support Module (CSM) can boot pure GPT disks in BIOS mode without needing a hybrid MBR. This is the right answer for almost all dual-boot scenarios in 2026. Hybrid MBR is a legacy workaround for an era when UEFI wasn’t universal; in 2026 it’s mostly a recovery hazard with diminishing benefits.

GPT advantages and drawbacks

👥 Researched & Reviewed By

Marcus Whitfield

Data Recovery Software Analyst & Senior Writer

All Articles X (Twitter)

Marcus has evaluated data recovery tools for more than six years across Windows, macOS, and Linux, from free utilities to enterprise-grade platforms. He writes the technical reference content on Data Recovery Fix, with particular interest in partition table mechanics and the practical realities of GPT recovery in modern UEFI environments.

B.Sc. Computer Science 6+ years data recovery evaluation Storage layer mechanics

Rachel Dawson

Technical Approver · Data Recovery Engineer

All Articles X (Twitter)

Rachel brings over twelve years of cleanroom data recovery experience, including hands-on GPT primary-from-backup recovery via gdisk and sgdisk, partition table reconstruction on physically damaged drives, and recovery from imaging-to-smaller-destination scenarios. She validates terminology and ensures published reference content reflects actual lab outcomes.

12+ years data recovery engineering PC-3000 certified GPT internals specialist