Prueba de recuperación tras daños en el cabezal GPT
A Prueba de recuperación tras daños en el cabezal del GPT pregunta si una copia de seguridad conservada puede reconstruir los metadatos de una partición dañada. En el ejemplo generado a continuación, sí es posible, siempre que la cabecera de la copia de seguridad y su matriz de entradas sean válidas y describan la estructura prevista. Sin embargo, el hecho de que el CRC de la cabecera coincida no garantiza por sí solo que la tabla de particiones sea utilizable. Este experimento calcula siete estados de metadatos, incluidos dos contraejemplos que superan la suma de comprobación de la cabecera. A continuación, reconstruye la GPT principal a partir de la copia de seguridad y compara el resultado con el valor de referencia.
Índice
Pregunta de investigación y alcance
La pregunta es concreta: tras un cambio concreto cerca del principio de un disco GPT, ¿permiten los metadatos que se han conservado reconstruir el GPT primario original?
Esta prueba controlada, a nivel de byte, crea metadatos GPT en memoria, aplica los cambios definidos y valida las sumas de comprobación resultantes, los campos de ubicación y la reconstrucción comparándolos con una referencia sin modificar.
La prueba evalúa la integridad del mapa de particiones: si cada copia GPT se valida correctamente, si una copia de seguridad conservada permite la reconstrucción y si los metadatos reconstruidos coinciden con la referencia. Para conocer las definiciones de los campos en los que se basa el experimento, consulta el Guía sobre la estructura de la cabecera GPT y el CRC32.
Configuración de referencia y supuestos
La configuración de referencia es un ejemplo de disco lógico de 64 MiB. Esta estructura compacta facilita el seguimiento de las direcciones y aísla los efectos de los cambios en los encabezados GPT y en las matrices de entradas.
Parámetro | Configuración de referencia |
Capacidad lógica | 67 108 864 bytes; 131 072 bloques lógicos |
Tamaño de bloque lógico | 512 bytes |
Esquema de particiones | Revisión 1.0 de GPT; MBR de protección |
Tamaños de los encabezados y de las matrices | Encabezados de 92 bytes; 128 entradas de 128 bytes cada una |
Partición activa | Un registro de datos básicos de Microsoft denominado LAB-DATA |
Contenido de la partición | Patrón de bytes determinista para comprobaciones de integridad de todo el rango |
El registro «Microsoft Basic Data» describe el rango de partición y el uso previsto. Su carga útil sigue un patrón de bytes determinista, lo que permite realizar una comparación exacta antes del daño y tras la reconstrucción.
Las notas de cálculo ampliables de la comparación indican tanto las ubicaciones de los metadatos como los límites utilizables y la extensión exacta de la partición activa. Todos los LBA son relativos al inicio de este disco lógico. El Guía sobre el direccionamiento de bloques lógicos explica cómo convertirlos en desplazamientos de bytes.
Procedimiento del experimento
Las etiquetas S0–S6 Identifica los siete estados de muestra generados que se utilizan en los resultados y en el selector de escenarios. No se trata de operaciones de daño consecutivas en un mismo disco. S0 es la referencia sin modificar; S1–S5 parten cada uno de una copia independiente de S0. Solo S6 parte de S3.
Todos los cambios se han realizado en copias generadas de un solo uso. No realices estas operaciones que pueden dañar los datos en una unidad que contenga datos necesarios.
S0 — Situación inicial: ambas copias del GPT están intactas.
Crea el MBR de protección, los encabezados principal y de copia de seguridad, y las matrices de entradas idénticas. Verifica las sumas de comprobación, los campos de ubicación, las dimensiones de las matrices y los límites de las particiones. Mantén este estado sin cambios como referencia para todas las comparaciones.
S1 — Byte de cabecera principal dañado.
Cambia el primer elemento del encabezado principal GUID del disco byte en el desplazamiento relativo a la cabecera +0x38 de 33 a 32. No modifiques el CRC de la cabecera almacenada. Mantén sin cambios ambas matrices, la cabecera de copia de seguridad y el contenido de la partición. De este modo se aísla una discrepancia entre la cabecera y el CRC.
S2 — Falta el encabezado principal.
Sustituye el bloque de 512 bytes situado en la LBA 1 por ceros. Conserva la matriz principal y la GPT de copia de seguridad completa. Comprueba si la copia de seguridad conservada constituye una fuente válida para la reconstrucción cuando la cabecera principal no tenga una firma reconocible.
S3 — Matriz de entrada principal dañada.
En la entrada 0 de la matriz principal, en la LBA 2, cambia el byte de nombre en el desplazamiento relativo a la entrada +0x38 de 4C a 4D, cambiando L por M. Deja ambos encabezados sin modificar. Esto permite aislar una discrepancia en el CRC de la matriz, mientras que el CRC del encabezado principal sigue siendo válido.
S4 — Faltan ambos cabezales.
Sustituye los bloques de cabecera principal y de respaldo, situados en LBA 1 y LBA 131071, por ceros. Conserva ambas matrices de entradas y el contenido de las particiones. Esto pone a prueba el límite de la reconstrucción cuando no se conserva ninguna cabecera válida.
S5 — Encabezado de copia de seguridad copiado sin adaptaciones.
Copia el bloque de cabecera de la copia de seguridad tal cual en el LBA 1. No modifiques sus campos de ubicación ni su suma de comprobación. De este modo se comprueba si un CRC de cabecera válido puede coexistir con direcciones incorrectas del lado primario.
S6 — GPT principal reconstruida a partir de S3.
Empieza por el daño de la matriz definido en S3. Restaura la matriz principal a partir de su copia de seguridad verificada, adapta los campos de ubicación de la cabecera de la copia de seguridad al lado principal y vuelve a calcular el CRC de la cabecera. Compara los metadatos reconstruidos, byte a byte, con los de S0.
Para cada estado, comprueba por separado el CRC del encabezado, el CRC de la matriz y las relaciones de ubicación. Si falta una cabecera, las comprobaciones asociadas no estarán disponibles; una coincidencia del CRC por sí sola no garantiza que el GPT sea válido. Compara por separado todo el rango de contenido de la partición, incluido su SHA-256, con S0. La condición para que la comprobación sea satisfactoria es que el diseño del GPT sea coherente y se conserve el rango de contenido de la partición.
Resultados de la prueba de recuperación tras daños en el cabezal del GPT
Las tres vistas renderizadas que se muestran a continuación mantienen la misma zona de encabezado en pantalla. Sigue el byte resaltado en la fila +0030, column 08—header offset +0x38—and compare the stored and calculated header CRCs. The views render the same sample bytes used in the checksum and reconstruction checks.
Primary GPT corruption test: before damage
The baseline primary header contains 33 en DiskGUID +0x38. Its stored and calculated header CRCs match. The primary array and the backup GPT also validate.
GPT header hex comparison: after one byte changes
S1 changes only that byte from 33 a 32. The stored header CRC remains unchanged, but the calculated CRC differs. The red outline identifies the changed byte, while the shaded checksum bytes show the value that was not updated. The valid backup remains a possible reconstruction source in this defined layout.
Backup GPT header recovery experiment: after reconstruction
The reconstruction adapts the verified backup header for the primary location and recalculates its checksum. The outlined byte returns to 33; the stored and calculated CRCs match again. A full byte comparison confirms that the rebuilt primary metadata equals the baseline. This calculated S1-to-baseline transition is separate from S6, which repairs the array damage below.
Array damage: why a passing header CRC is not enough
S3 changes the first partition-name character from L to M in the entry array. The header bytes remain unchanged, so its CRC passes while the array CRC fails. S6 restores the backup array and rebuilds the primary header, returning the original metadata to the baseline.
En GPT partition entry array guide explains why the name belongs to the array rather than the header.
Failure conditions that change the interpretation
The collapsed scenario table retains the remaining checks. With the primary header missing (S2), the intact backup still supports reconstruction. With both headers missing (S4), no valid header remains as a reconstruction source, even though the defined arrays survive. Finally, copying the backup header verbatim to LBA 1 (S5) preserves its valid CRC but leaves incorrect primary location fields.
These outcomes distinguish a matching checksum from a consistent partition map. A valid reconstruction requires checksums and location relationships to agree with the intended layout.
Use the scenario explorer below to compare all seven states in Hex. Start with S0, then switch between S1–S6 to inspect the primary header and the entry-array excerpt alongside the CRC and location checks. Red marks bytes that differ from S0; green in S6 marks reconstructed fields that match the baseline.
CRC values and all seven scenarios
0x867AACB5 → 0x867AACB50xB0F8E8C0 → 0x21E2966D| Escenario | Header CRC | Array CRC | Ubicación | Copia de seguridad de GPT | Calculated interpretation |
|---|---|---|---|---|---|
| S0 · Baseline | PASS | PASS | PASS | VALID | Both GPT copies validate. |
| S1 · Header bit flip | FAIL | PASS | PASS | VALID | Backup header and array remain usable for reconstruction. |
| S2 · Primary header missing | Unavailable | Unavailable | Unavailable | VALID | Backup header and array remain usable for reconstruction. |
| S3 · Primary array damaged | PASS | FAIL | PASS | VALID | Primary header CRC passes, but its array CRC fails; backup remains valid. |
| S4 · Both headers missing | Unavailable | Unavailable | Unavailable | Missing | No valid header remains; automatic header-to-header reconstruction is unsupported. |
| S5 · Blind backup copy | PASS | PASS | FAIL | VALID | CRC passes, but MyLBA and primary array placement fail. |
| S6 · Rebuilt primary | PASS | PASS | PASS | VALID | Primary GPT equals the baseline; both copies validate. |
Header CRC: 92 bytes with +0x10–+0x13 zeroed. Array CRC: 128 × 128 = 16,384 bytes. Location checks validate MyLBA and primary-array placement. Missing headers make these checks unavailable.
Generated 64 MiB sample · 512-byte blocks · header and entry bytes switch with the scenario; checks are precomputed.
Why the Results Follow from the Mechanism
UEFI 2.11, Section 5.3.2 defines separate header and entry-array checks. The header CRC covers Tamaño del encabezado bytes with CRC32 de cabecera temporarily zeroed. The array CRC covers Número de entradas de partición × Tamaño de una entrada de partición bytes. Location checks add information that neither checksum supplies.
In this sample, S1 changes a header-CRC input. S3 changes an array-CRC input. S5 preserves the header-CRC input but violates the primary location requirements. These controlled differences explain the three distinct validation outcomes shown in the explorer.
The sample also explains why the primary and backup header checksums differ at baseline: their location-dependent fields differ. Identical arrays can share a checksum while their associated headers do not.
Practical Interpretation and Limitations
On a real disk, first preserve the source and identify the correct device by model or serial number, capacity, and logical block size. Perform any proposed metadata writes on a disposable working copy. A USB bridge, a resized image, or a truncated acquisition can change the address context; do not substitute this sample’s last LBA for the actual device boundary.
Next, establish whether a surviving backup describes the intended current layout. A correct CRC detects certain byte changes; it does not prove freshness or authenticity. UEFI specifically warns about stale backup GPT metadata after a disk has been reformatted for legacy MBR use. Conflicting copies require investigation before either is accepted as authoritative.
Microsoft’s Windows and GPT FAQ provides background on GPT redundancy and CRC protection. Recovery behavior depends on the operating system, the tool, and platform policy. Confirm which GPT copy a tool accepts and which metadata ranges it proposes to change before approving a repair.
After metadata reconstruction, confirm the expected partition boundaries, inspect the file system without modifying the source, and verify representative files against known copies where available. For a system disk, follow this with a boot check on the intended target. These checks establish file accessibility and startup readiness after the partition map has been validated.
When File Recovery Comes Before GPT Repair
When a partition disappears or its volume becomes inaccessible, securing important files may take priority over writing changes to the GPT. Magic Data Recovery’s lost-partition workflow can scan for recoverable files, preview supported file types, and save selected data to another drive. After recovering the files you need, assess the partition layout and plan any metadata repair on a working copy. Keep file recovery and GPT reconstruction as separate tasks, with separate checks for recovered files and partition-table integrity.
Conclusión
Este Prueba de recuperación tras daños en el cabezal del GPT demonstrates how a valid backup can support reconstruction after primary-header corruption or loss. In the tested sample, restoring the entry array and adapting the header’s location fields returned the primary GPT to its baseline bytes. The decisive condition is that the surviving backup header and its associated array both validate and describe the intended partition layout.
The comparisons also show why a passing header CRC32 is insufficient: entry-array damage can leave the header checksum unchanged, while an unmodified backup header can retain a valid checksum at the wrong location. Reliable GPT recovery therefore requires agreement between header checksums, array checksums, and location fields. After reconstruction, verify partition boundaries, file-system access, and important files separately; system disks also need a boot check. A restored partition map establishes metadata consistency, while these additional checks determine whether the disk is usable again.
FAQ About GPT Header Damage and Recovery
¿Cómo puedo comprobar si el encabezado GPT está dañado?
¿Se puede reparar un encabezado GPT dañado a partir de la copia de seguridad?
¿La copia de seguridad GPT conserva las particiones que se han eliminado?
¿La recuperación del encabezado GPT permite restaurar archivos sin pérdida de datos?
¿Qué ocurre si tanto el encabezado GPT principal como el de respaldo están dañados?
¿Cómo puedo probar la recuperación del encabezado GPT de forma segura?
¿Se soluciona el fallo de arranque de Windows reparando el encabezado GPT?
