Test di ripristino in caso di danneggiamento dell'intestazione GPT
A Test di ripristino in caso di danneggiamento dell'intestazione GPT si chiede se un backup integro possa ricostruire i metadati di una partizione danneggiata. Nell’esempio generato riportato di seguito, ciò è possibile, a condizione che l’intestazione del backup e il relativo array di voci siano validi e descrivano la struttura prevista. Tuttavia, un CRC dell’intestazione corrispondente da solo non garantisce che la tabella delle partizioni sia utilizzabile. Questo esperimento calcola sette stati dei metadati, inclusi due controesempi che superano il checksum dell’intestazione. Successivamente ricostruisce la GPT primaria dal backup e verifica il risultato rispetto al valore di riferimento.
Indice dei contenuti
Domanda di ricerca e ambito di studio
La domanda è precisa: dopo una modifica ben definita all’inizio di un disco GPT, i metadati rimasti consentono di ricostruire il GPT primario originale?
Questo test controllato a livello di byte crea i metadati GPT in memoria, applica le modifiche definite e verifica la validità dei checksum risultanti, dei campi di posizione e della ricostruzione rispetto a una linea di riferimento invariata.
Il test valuta l'integrità della mappa delle partizioni: verifica se ogni copia GPT è valida, se un backup disponibile consente la ricostruzione e se i metadati ricostruiti corrispondono al valore di riferimento. Per le definizioni dei campi alla base dell'esperimento, consultare il Struttura dell'intestazione GPT e guida al CRC32.
Configurazione di riferimento e ipotesi
La configurazione di riferimento è un esempio di disco logico da 64 MiB. Questa struttura compatta rende gli indirizzi facili da seguire e isola gli effetti delle modifiche apportate alle intestazioni GPT e agli array di voci.
Parametro | Configurazione di riferimento |
Capacità logica | 67.108.864 byte; 131.072 blocchi logici |
Dimensione del blocco logico | 512 byte |
Schema di partizionamento | Revisione GPT 1.0; MBR di protezione |
Dimensioni delle intestazioni e degli array | intestazioni da 92 byte; 128 voci da 128 byte ciascuna |
Partizione attiva | Una voce di Microsoft Basic Data denominata LAB-DATA |
Contenuto della partizione | Modello deterministico di byte per i controlli di integrità su tutto l'intervallo |
Il campo “Microsoft Basic Data” descrive l’intervallo della partizione e l’uso previsto. Il suo contenuto segue uno schema deterministico di byte, consentendo un confronto esatto tra lo stato precedente al danneggiamento e quello successivo alla ricostruzione.
Le note di calcolo espandibili del confronto riportano sia le posizioni dei metadati, sia i limiti utilizzabili, sia l'estensione esatta della partizione attiva. Tutti gli LBA sono relativi all'inizio di questo disco logico. Il Guida all'indirizzamento a blocchi logici spiega come convertirli in offset in byte.
Procedura sperimentale
Le etichette S0–S6 Identificare i sette stati di esempio generati utilizzati nei risultati e nel selettore di scenari. Non si tratta di operazioni di danneggiamento consecutive su un unico disco. S0 è il riferimento invariato; S1–S5 partono ciascuno da una copia indipendente di S0. Solo S6 parte da S3.
Tutte le modifiche sono state apportate a copie generate ad uso singolo. Non eseguire queste operazioni che comportano la perdita di dati su un'unità contenente dati necessari.
S0 — Condizione iniziale: entrambe le copie del GPT sono intatte.
Creare l'MBR di protezione, le intestazioni primaria e di backup e gli array di voci identici. Verificare i checksum, i campi di posizione, le dimensioni degli array e i limiti delle partizioni. Mantenere questo stato invariato come riferimento per ogni confronto.
S1 — Byte di intestazione primaria danneggiato.
Modifica il primo elemento dell'intestazione principale DiskGUID byte all'offset relativo all'intestazione +0x38 da 33 a 32. Lasciare invariato il CRC dell'intestazione memorizzata. Mantenere invariati entrambi gli array, l'intestazione di backup e il contenuto della partizione. In questo modo si individua un'incongruenza tra l'intestazione e il CRC.
S2 — Manca l'intestazione principale.
Sostituisci il blocco da 512 byte all'LBA 1 con degli zeri. Conserva l'array primario e il GPT di backup completo. Verifica se il backup rimasto costituisce una fonte valida per la ricostruzione nel caso in cui l'intestazione primaria non presenti una firma riconoscibile.
S3 — Matrice di ingresso primaria danneggiata.
Nella voce 0 dell'array primario all'LBA 2, modificare il byte del nome all'offset relativo alla voce +0x38 da 4C a 4D, sostituendo L con M. Lasciare entrambe le intestazioni invariate. In questo modo si individua una discrepanza nel CRC dell'array, mentre il CRC dell'intestazione primaria risulta ancora corretto.
S4 — Mancano entrambe le testate.
Sostituisci i blocchi di intestazione primaria e di backup, situati rispettivamente a LBA 1 e LBA 131071, con zeri. Mantieni entrambi gli array di voci e il contenuto delle partizioni. Questo test verifica il limite della ricostruzione quando nessuna delle due intestazioni valide è rimasta intatta.
S5 — Intestazione di backup copiata senza modifiche.
Copia il blocco di intestazione di backup alla lettera all'LBA 1. Non modificare i campi relativi alla posizione né il checksum. Questo permette di verificare se un CRC dell'intestazione valido possa coesistere con indirizzi errati sul lato primario.
S6 — GPT primario ricostruito a partire da S3.
Iniziare con il danno all'array definito in S3. Ripristinare l'array primario dal suo backup verificato, adattare i campi di posizione dell'intestazione del backup per il lato primario e ricalcolare il CRC dell'intestazione. Confrontare i metadati ricostruiti byte per byte con quelli di S0.
Per ogni stato, verificare separatamente il CRC dell'intestazione, il CRC dell'array e le relazioni di posizione. L'assenza dell'intestazione rende indisponibili i controlli associati; un CRC corrispondente da solo non garantisce la validità del GPT. Confrontare separatamente l'intero intervallo di contenuto della partizione, compreso il suo SHA-256, con S0. La condizione di superamento del test è un layout GPT coerente con l'intervallo di contenuto della partizione preservato.
Risultati del test di ripristino in caso di danneggiamento dell'intestazione GPT
Le tre viste renderizzate riportate di seguito mantengono la stessa area di intestazione sullo schermo. Segui il byte contornato alla riga +0030, colonna 08—offset dell'intestazione +0x38—e confrontare i CRC delle intestazioni memorizzati e quelli calcolati. Le visualizzazioni riproducono gli stessi byte di esempio utilizzati nei controlli del checksum e di ricostruzione.
Test preliminare di integrità del GPT: prima del danneggiamento
L'intestazione primaria di riferimento contiene 33 a DiskGUID +0x38. I valori CRC delle intestazioni memorizzati e calcolati corrispondono. Anche l'array primario e il GPT di backup risultano validi.
Confronto esadecimale dell'intestazione GPT: dopo la modifica di un byte
S1 modifica solo quel byte da 33 a 32. Il CRC dell'intestazione memorizzata rimane invariato, ma il CRC calcolato è diverso. Il contorno rosso evidenzia il byte modificato, mentre i byte del checksum ombreggiati mostrano il valore che non è stato aggiornato. Il backup valido rimane una possibile fonte di ricostruzione in questo layout definito.
Esperimento di recupero dell'intestazione GPT di backup: dopo la ricostruzione
La ricostruzione adatta l'intestazione del backup verificata per la posizione primaria e ne ricalcola il checksum. Il byte indicato torna a 33; i CRC memorizzati e quelli calcolati coincidono nuovamente. Un confronto byte per byte conferma che i metadati primari ricostruiti corrispondono alla linea di base. Questa transizione calcolata da S1 alla linea di base è distinta da S6, che ripara il danno all’array descritto di seguito.
Danni all'array: perché un CRC di intestazione di passaggio non è sufficiente
S3 modifica il primo carattere del nome della partizione da L a M nell'array delle voci. I byte dell'intestazione rimangono invariati, quindi il CRC dell'intestazione viene superato mentre quello dell'array fallisce. S6 ripristina l'array di backup e ricostruisce l'intestazione primaria, riportando i metadati originali allo stato iniziale.
Il Guida all'array delle voci delle partizioni GPT spiega perché il nome appartiene all'array anziché all'intestazione.
Condizioni di errore che modificano l'interpretazione
La tabella degli scenari compressa conserva i controlli rimanenti. In assenza dell’intestazione primaria (S2), la copia di backup intatta consente comunque la ricostruzione. In assenza di entrambe le intestazioni (S4), non rimane alcuna intestazione valida come fonte di ricostruzione, anche se gli array definiti sono ancora integri. Infine, copiando alla lettera l’intestazione di backup all’LBA 1 (S5) si preserva il suo CRC valido, ma si ottengono campi di posizione primaria errati.
Questi risultati distinguono un checksum corrispondente da una mappa di partizione coerente. Una ricostruzione valida richiede che i checksum e le relazioni di posizione siano in accordo con la struttura prevista.
Utilizza l'esploratore di scenari qui sotto per confrontare tutti e sette gli stati in Hex. Inizia con S0, quindi passa da S1 a S6 per esaminare l'intestazione primaria e l'estratto dell'array di ingresso insieme ai controlli CRC e di posizione. Il colore rosso indica i byte che differiscono da S0; il verde in S6 indica i campi ricostruiti che corrispondono alla linea di base.
CRC values and all seven scenarios
0x867AACB5 → 0x867AACB50xB0F8E8C0 → 0x21E2966D| Scenario | CRC dell'intestazione | CRC dell'array | Posizione | Backup GPT | Calculated interpretation |
|---|---|---|---|---|---|
| S0 · Valori di riferimento | PASS | PASS | PASS | VALIDO | Both GPT copies validate. |
| S1 · Inversione del bit di intestazione | FALLITO | PASS | PASS | VALIDO | Backup header and array remain usable for reconstruction. |
| S2 · Mancanza dell'intestazione principale | Unavailable | Unavailable | Unavailable | VALIDO | Backup header and array remain usable for reconstruction. |
| S3 · Matrice primaria danneggiata | PASS | FALLITO | PASS | VALIDO | Il CRC dell'intestazione primaria è corretto, ma quello dell'array non lo è; il backup rimane valido. |
| S4 · Mancano entrambe le testate | Unavailable | Unavailable | Unavailable | Missing | No valid header remains; automatic header-to-header reconstruction is unsupported. |
| S5 · Copia di backup automatica | PASS | PASS | FALLITO | VALIDO | CRC passes, but MyLBA and primary array placement fail. |
| S6 · Primario revisionato | PASS | PASS | PASS | VALIDO | 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 Dimensione intestazione bytes with HeaderCRC32 temporarily zeroed. The array CRC covers NumeroDiVociDellaPartizione × DimensioneDiUnaVoceDellaPartizione 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.
Conclusione
Questo Test di ripristino in caso di danneggiamento dell'intestazione 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
Come faccio a verificare se un'intestazione GPT è danneggiata?
È possibile riparare un’intestazione GPT danneggiata utilizzando il backup?
Il backup GPT conserva le partizioni che sono state eliminate?
Il recupero dell'intestazione GPT consente di ripristinare i file senza perdita di dati?
Cosa succede se sia l'intestazione GPT primaria che quella di backup sono danneggiate?
Come posso testare in modo sicuro il recupero dell'intestazione GPT?
La riparazione dell'intestazione GPT risolverà il problema di avvio di Windows?
