Intestazione GPT: struttura, backup e CRC32
A Intestazione GPT è una struttura di metadati che descrive la tabella delle partizioni GUID (GUID Partition Table) di un disco. Identifica il disco, individua l’array delle voci delle partizioni, definisce i limiti utilizzabili del disco e memorizza i checksum utilizzati per rilevare eventuali danneggiamenti dei metadati. La GPT mantiene un’intestazione primaria e una di backup a scopo di ridondanza. Comprendere la disposizione dei byte e i campi CRC32 aiuta a spiegare come vengono convalidate le informazioni sulle partizioni e perché un’intestazione danneggiata non implica necessariamente la perdita dei file sottostanti.
Indice dei contenuti
Che cos’è un’intestazione GPT?
L'intestazione GPT fa parte della GUID Partition Table (GPT), lo schema di partizionamento del disco definito dalla specifica UEFI.
A differenza del precedente schema Master Boot Record (MBR), il GPT conserva due copie dei metadati delle partizioni: una all’inizio del disco e un’altra verso la fine.
Ogni intestazione GPT contiene le informazioni necessarie per individuare e interpretare l'array di voci di partizione ad essa associato, tra cui:
- Una firma che identifica il formato GPT.
- Revisione e dimensione dell'intestazione GPT.
- La posizione dell'intestazione stessa e quella dell'intestazione alternativa.
- Il primo e l'ultimo indirizzo di blocco logico utilizzabile.
- Un identificatore univoco del disco.
- La posizione e le dimensioni dell'array delle voci di partizione.
- Checksum CRC32 per verificare l'integrità dei metadati.
L'intestazione GPT non memorizza direttamente i nomi dei file, le strutture delle cartelle o i contenuti dei file. Questi elementi appartengono ai file system all'interno delle partizioni.
Per una panoramica dello schema di partizionamento, consultare GPT (Tabella delle partizioni GUID). Le definizioni ufficiali sono riportate nel Specifiche UEFI, Sezione 5.3.
Dove si trova l'intestazione GPT?
GPT colloca i metadati primari e di backup alle estremità opposte di un disco.
Per un disco GPT convenzionale:
Posizione | Indice |
LBA 0 | MBR protettivo |
LBA 1 | Intestazione GPT primaria |
A seguito degli LBA | Matrice delle voci delle partizioni primarie |
Intervallo LBA utilizzabile | Spazio disponibile per le partizioni |
LBA prima del blocco finale | Array di voci delle partizioni di backup |
Ultimo LBA | Backup dell'intestazione GPT |
L'MBR di protezione contribuisce a impedire che i vecchi strumenti, compatibili solo con l'MBR, considerino il disco GPT come non allocato.
È diverso dall'intestazione GPT stessa. Per un confronto con i metadati delle partizioni tradizionali, si veda Tabella partizioni MBR.
Settori logici e indirizzi in byte
GPT utilizza indirizzi di blocco logici (LBA), anziché offset assoluti in byte, per identificare le proprie strutture.
Per convertire un LBA in un offset in byte:
Offset in byte = LBA × Dimensione logica del blocco
Ad esempio:
- Su un disco con blocchi logici da 512 byte, l'intestazione primaria inizia all'offset di byte
512(0x200). - Su un disco con blocchi logici da 4.096 byte, l'intestazione primaria inizia all'offset di byte
4096(0x1000).
L'intestazione occupa in genere 92 byte all'interno di un blocco logico, sebbene il formato consenta l'uso di intestazioni più grandi, fino alla dimensione del blocco logico.
Un’intestazione di 92 byte non va confusa con un settore da 512 byte. I byte rimanenti di un blocco di intestazione da 512 byte sono riservati e devono essere pari a zero.
Struttura dell'intestazione GPT: campi, offset e dimensioni
La struttura dell'intestazione GPT è definita in Specifiche UEFI 2.10, Tabella 5.5.
I seguenti offset sono relativi all'inizio dell'intestazione GPT, non all'inizio del disco.
Campo | Offset (esadecimale) | Dimensione | Scopo |
Firma |
| 8 byte | Identifica l'intestazione GPT |
Revisione |
| 4 byte | Revisione del formato GPT |
Dimensione intestazione |
| 4 byte | Lunghezza dell'intestazione in byte |
HeaderCRC32 |
| 4 byte | Checksum dell'intestazione |
Riservato |
| 4 byte | Deve essere zero |
MyLBA |
| 8 byte | Posizione di questa intestazione |
AlternateLBA |
| 8 byte | Posizione dell'altra intestazione |
Primo LBA utilizzabile |
| 8 byte | Primo blocco di partizione utilizzabile |
LastUsableLBA |
| 8 byte | Ultimo blocco di partizione utilizzabile |
DiskGUID |
| 16 byte | Identificatore univoco del disco |
PartitionEntryLBA |
| 8 byte | Inizio dell'array di voci associato |
Numero di voci di partizione |
| 4 byte | Numero di posti disponibili |
Dimensione della voce di partizione |
| 4 byte | Dimensione di ciascuna voce |
PartitionEntryArrayCRC32 |
| 4 byte | Checksum dell'array delle voci |
I campi definiti occupano degli offset 0x00 attraverso 0x5B, per un totale di 92 byte. I byte provenienti da 0x5C fino alla fine del blocco logico sono riservati.
Firma e revisione
Un'intestazione GPT valida inizia con la firma ASCII EFI PARTE.
Gli otto byte sono:
45 46 49 20 50 41 52 54
Lo standard GPT versione 1.0 è rappresentato dai seguenti byte in formato little-endian:
00 00 01 00
Questi rappresentano il valore numerico 0x00010000. La revisione dell'intestazione GPT non corrisponde alla versione della specifica UEFI.
La dimensione dell'intestazione comunemente utilizzata è di 92 byte, codificata come segue:
5C 00 00 00
GUID del disco e ordine dei byte
Il campo DiskGUID occupa 16 byte, a partire dall'offset 0x38.
Identifica il disco GPT. È diverso dal GUID univoco della partizione memorizzato all’interno di ciascuna singola voce di partizione.
Un GUID introduce inoltre un dettaglio importante nell'interpretazione dei dati esadecimali grezzi: i suoi primi tre componenti utilizzano l'ordine dei byte "little-endian", mentre gli ultimi otto byte mantengono l'ordine in cui vengono visualizzati.
Ad esempio, il GUID illustrativo:
f0e1d2c3-b4a5-4c6d-8e9f-102030405060
viene memorizzato come:
C3 D2 E1 F0 A5 B4 6D 4C 8E 9F 10 20 30 40 50 60
Leggere tutti i 16 byte grezzi direttamente da sinistra a destra produrrebbe un GUID testuale errato.
Campi dell'array delle voci di partizione
Tre campi definiscono l'array delle voci di partizione:
PartitionEntryLBAindica dove inizia l'array.Numero di voci di partizionedefinisce il numero delle voci.Dimensione della voce di partizionedefinisce la dimensione di ciascuna voce.
La lunghezza in byte dell'array viene calcolata come segue:
Dimensione dell'array = Numero di voci × Dimensione di ciascuna voce
Per un array contenente 128 elementi, ciascuno di 128 byte:
128 × 128 = 16.384 byte
Con blocchi logici da 512 byte:
16.384 ÷ 512 = 32 blocchi logici
Si tratta dello spazio riservato all'array delle voci di partizione, non dello spazio occupato dai dati effettivi dei file.
L'attuale specifica UEFI definisce la dimensione della voce come 128 × 2^n byte, dove n è un numero intero non negativo. I dischi GPT tipici utilizzano voci da 128 byte.
Each slot in the partition entry array describes one partition through its type GUID, unique partition GUID, LBA boundaries, attributes, and name. For a field-by-field explanation of the Struttura delle voci delle partizioni GPT, including byte offsets and GUID encoding, see our Voce di partizione GPT: campi “Structure”, “Array” e “GUID” guida.
Header GPT primari e di backup: cosa cambia?
Le intestazioni GPT primaria e di backup hanno la stessa struttura dei campi, ma non contengono byte identici.
Le loro posizioni e alcuni puntatori interni differiscono.
Si consideri un disco GPT di esempio con:
- 100.000 blocchi logici, numerati
0attraverso99,999. - Una dimensione del blocco logico pari a 512 byte.
- Un array di voci contenente 128 slot da 128 byte ciascuno.
- Un array di voci di partizione composto da 32 blocchi a ciascuna estremità.
La struttura è la seguente:
Struttura | GPT primario | Backup GPT |
LBA di intestazione |
|
|
MyLBA |
|
|
AlternateLBA |
|
|
PartitionEntryLBA |
|
|
Estensione dell'array di voci |
|
|
Primo LBA utilizzabile |
|
|
LastUsableLBA |
|
|
Dimensione dell'intestazione | 92 byte | 92 byte |
Queste posizioni derivano direttamente dalla dimensione del disco e dai due array di voci di partizione da 32 blocchi.
Ad esempio:
Inizio dell'array di backup = Ultimo LBA − Blocchi dell'array
99.999 − 32 = 99.967
L'ultimo blocco utilizzabile deve precedere quell'array di backup:
99.967 − 1 = 99.966
Entrambe le intestazioni descrivono quindi lo stesso intervallo di disco utilizzabile, ma indicano posizioni fisiche diverse per i rispettivi array di voci di partizione.
Questa configurazione consente ai software compatibili con GPT di verificare i metadati di backup nel caso in cui la copia primaria risulti danneggiata.
Tuttavia, la presenza di due copie non garantisce che nessuna delle due sia valida o aggiornata.
Esempio pratico: decodifica dell’intestazione GPT da byte esadecimali
L'esempio seguente utilizza metadati GPT creati appositamente, non byte acquisiti da un disco fisico.
Descrive lo stesso disco da 100.000 blocchi utilizzato in precedenza.
L'esempio non contiene partizioni popolate. Tutti i 128 slot delle voci delle partizioni sono riempiti con zeri, consentendo il calcolo dei checksum di entrambi gli array di voci a partire da un input completamente definito.
Fase 1: Identificare l'intestazione
All'inizio dell'intestazione primaria, i primi 16 byte sono:
45 46 49 20 50 41 52 54 00 00 01 00 5C 00 00 00
Dividi la sequenza per campo:
Intervallo di byte | Byte esadecimali | Significato decodificato |
|
|
|
|
| Revisione |
|
| Dimensione dell'intestazione: 92 byte |
La firma, la revisione e le dimensioni dell'intestazione corrispondono al formato previsto.
Ciò costituisce un’intestazione plausibile, ma di per sé non dimostra che il GPT sia valido.
Fase 2: Decodifica dei campi relativi alla posizione
L'intestazione principale contiene:
Campo | Byte memorizzati | Valore decodificato |
MyLBA |
|
|
AlternateLBA |
|
|
Primo LBA utilizzabile |
|
|
LastUsableLBA |
|
|
PartitionEntryLBA |
|
|
Questi valori utilizzano l'ordine dei byte "little-endian".
Ad esempio, i byte 9F 86 01 00 00 00 00 00 rappresentare 0x000000000001869F, oppure in formato decimale 99,999.
L'intestazione di backup si inverte MyLBA e AlternateLBA e le modifiche PartitionEntryLBA a 99,967.
Fase 3: Confronta i checksum delle intestazioni
Per questo specifico esempio sintetico, utilizzando il DiskGUID indicato in precedenza e un array di voci di partizione da 16.384 byte riempito con zeri, i valori calcolati sono:
Checksum | GPT primario | Backup GPT |
HeaderCRC32 |
|
|
PartitionEntryArrayCRC32 |
|
|
I checksum delle intestazioni differiscono perché le intestazioni contengono campi di posizione diversi.
I checksum dell'array delle voci di partizione corrispondono perché i due array contengono byte identici riempiti di zeri.
Si tratta di valori di esempio calcolati, non di costanti universali per il checksum GPT. Un GUID del disco diverso, una diversa struttura delle partizioni o una modifica dei metadati produrrebbero risultati diversi.
Come funziona la convalida CRC32 dell'intestazione GPT
GPT utilizza due checksum CRC32 distinti per rilevare eventuali modifiche nei metadati delle partizioni:
HeaderCRC32verifica l'intestazione GPT stessa.PartitionEntryArrayCRC32verifica l'array delle voci di partizione associate.
Entrambi utilizzano l'algoritmo CRC-32 standard, ma coprono intervalli di byte diversi.
HeaderCRC32: Come viene calcolato il checksum
Il HeaderCRC32 Il campo occupa quattro byte a un offset relativo all'intestazione 0x10.
Secondo il Specifiche UEFI, il checksum deve essere calcolato impostando temporaneamente questo campo a zero.
Il processo di verifica si articola in cinque fasi:
- Leggi l'intestazione. Recuperare i byte dell'intestazione GPT da un'immagine disco e determinare il
Dimensione intestazionecampo all'offset0x0C. - Registrare il valore CRC32 memorizzato. Leggi i quattro byte agli offset
0x10–0x13come valore a 32 bit in formato little-endian. - Azzerare il campo del checksum. In una copia temporanea, sostituisci questi quattro byte con
00 00 00 00. - Calcolare il CRC32. Calcolare il checksum CRC-32 standard su esattamente
Dimensione intestazionebyte. - Confronta i risultati. Se il valore calcolato corrisponde a quello memorizzato, l'intestazione supera il controllo di integrità CRC32.
Per un’intestazione GPT standard da 92 byte, il calcolo tiene conto degli offset 0x00–0x5B, non l'intero settore logico da 512 byte.
Un calcolatore CRC-32 standard oppure quello di Python zlib.crc32() è in grado di eseguire il calcolo. L'algoritmo utilizza il polinomio riflesso 0xEDB88320, un valore iniziale del registro pari a 0xFFFFFFFF, e un'operazione XOR finale su 0xFFFFFFFF.
Esempio: verifica del CRC32 dell'intestazione GPT
Si consideri l'intestazione GPT sintetica utilizzata in precedenza in questo articolo.
Articolo | Valore |
Dimensione intestazione |
|
CRC32 dell'intestazione memorizzata |
|
Byte memorizzati |
|
Campo CRC durante il calcolo |
|
CRC32 calcolato |
|
Risultato della convalida | Partita |
Il checksum calcolato corrisponde al valore memorizzato, il che indica che l'intestazione dell'esempio supera il controllo CRC32.
Se anche un solo byte interessato subisce una modifica senza che venga aggiornato il checksum memorizzato, il calcolo produrrà generalmente un risultato diverso.
Importante: Eseguire sempre il calcolo su una copia temporanea o su dati di lavoro in sola lettura. Non sovrascrivere i byte di checksum sul disco originale.
0x76EF8C67 in ordine little-endian. Seleziona Zero per vedere come viene preparato l'input.0xEDB88320 · Init 0xFFFFFFFF · XOR finale 0xFFFFFFFF. Esempio didattico, non dati effettivi del disco.PartitionEntryArrayCRC32: Verifica delle voci di partizione
Il secondo checksum, PartitionEntryArrayCRC32, è memorizzato a un offset relativo all'intestazione 0x58.
A differenza di HeaderCRC32, copre l'array delle voci delle partizioni anziché l'intestazione.
La sua lunghezza di calcolo è:
NumeroDiVociDellaPartizione × DimensioneDiUnaVoceDellaPartizione
Per un array contenente 128 elementi da 128 byte ciascuno:
128 × 128 = 16.384 byte
Per verificare questo checksum, calcolare il CRC32 sull'intero array di 16.384 byte e confrontare il risultato con il checksum memorizzato nell'intestazione GPT.
Nessun campo di checksum deve essere azzerato all'interno dell'array delle voci di partizione.
Gli array primario e di backup devono essere controllati separatamente poiché si trovano in posizioni diverse. Lo spazio di riempimento inutilizzato dopo l'ultima voce dell'array viene escluso dal calcolo.
Perché entrambi i checksum sono importanti
I due checksum rispondono a domande diverse:
- HeaderCRC32: Gli byte dell'intestazione corrispondono al checksum memorizzato nell'intestazione?
- PartitionEntryArrayCRC32: I byte della voce della partizione corrispondono al checksum memorizzato nell'intestazione?
Un'intestazione GPT può superare il proprio controllo CRC32 anche se l'array delle voci di partizione è danneggiato.
Allo stesso modo, entrambi i checksum potrebbero risultare corretti anche quando i confini delle partizioni sono logicamente errati o i metadati non sono aggiornati.
CRC32 verifica l'integrità dei metadati, non lo stato di salute del disco né la recuperabilità dei file. Sono necessari ulteriori controlli per verificare che le voci delle partizioni siano coerenti e che i file system sottostanti rimangano accessibili.
Come verificare se un'intestazione GPT è valida
Lo standard UEFI prevede che i software compatibili con GPT debbano verificare la firma dell'intestazione, il CRC dell'intestazione, MyLBA, e il CRC dell'array delle voci di partizione associato. Per il GPT primario, deve inoltre esaminare l'intestazione alternativa.
Un'ispezione pratica dovrebbe includere i seguenti ulteriori controlli di coerenza:
Controllo | Condizioni previste | Perché è importante |
Firma |
| Identifica la struttura |
Dimensione dell'intestazione | Almeno 92 byte; non più grande di un blocco logico | Definisce l'intervallo del checksum |
HeaderCRC32 | Risultati del ricalcolo del CRC32 | Rileva le modifiche ai byte dell'intestazione |
MyLBA | Corrisponde alla posizione fisica dell'intestazione | Rileva i metadati inseriti in modo errato |
AlternateLBA | Indica l'altra intestazione | Supporta la convalida ridondante del layout |
PartitionEntryLBA | Indica un array all’interno dei limiti del disco | Impedisce l'indirizzamento non valido degli array |
PartitionEntryArrayCRC32 | Corrisponde ai byte effettivi dell'array | Rileva il danneggiamento dell'array di voci |
Intervallo LBA utilizzabile | Ordinati, all’interno dei limiti e al di fuori delle aree dei metadati | Verifica la coerenza del layout |
Metadati primari/di backup | Coerente dove necessario | Rileva le copie in conflitto |
Il superamento di questi controlli non garantisce l'integrità dei singoli file system o dei singoli file. È inoltre necessario verificare la validità e l'eventuale sovrapposizione dei confini delle voci di partizione.
Il Requisiti di convalida UEFI GPT fornire la base normativa per stabilire se i metadati GPT siano validi.
Cosa succede quando un’intestazione GPT è danneggiata?
Le conseguenze dipendono dai metadati che rimangono utilizzabili.
Intestazione principale danneggiata, quella di riserva valida
Se il GPT primario non è valido, il software compatibile con GPT deve esaminare l'intestazione dell'ultimo blocco logico e verificare la validità dell'array delle voci di partizione ad esso associato.
Un backup valido può fornire i metadati necessari per ricostruire la copia primaria, nel rispetto delle politiche di ripristino della piattaforma.
Una riparazione di questo tipo comporta la scrittura dei metadati della partizione e non dovrebbe essere effettuata con leggerezza su un disco contenente dati importanti e non protetti.
Intestazione di backup danneggiata, primaria valida
La struttura delle partizioni primarie potrebbe essere ancora leggibile.
Tuttavia, è necessario ripristinare il backup per preservare la ridondanza GPT.
Un disco apparentemente accessibile può quindi presentare comunque metadati di backup danneggiati.
Entrambe le intestazioni non valide
Se nessuna delle due intestazioni è valida, il disco non presenta un'intestazione GPT valida secondo le regole di convalida UEFI.
Ciò non significa necessariamente che ogni partizione o file sia stato cancellato fisicamente.
I metadati delle partizioni, i metadati del file system e il contenuto dei file occupano aree diverse del disco.
Quando si tratta di file importanti, conservare il disco originale e distinguere recupero dati della partizione persa dalla riscrittura della tabella delle partizioni.
Intestazione valida ma informazioni sulla partizione errate
Un’intestazione strutturalmente valida non è sufficiente a garantire che le voci della partizione descrivano correttamente il disco corrente.
Ad esempio, i metadati GPT obsoleti possono rimanere alla fine di un disco dopo che un software di partizionamento di vecchia generazione ha modificato la struttura del disco.
Un backup che sembri valido deve quindi essere valutato tenendo conto dell’MBR di protezione, della capacità attuale del disco, delle voci relative alle partizioni e di altre prove disponibili.
L'UEFI mette espressamente in guardia dal fare affidamento su strutture GPT non aggiornate dopo che un disco è stato riformattato nel formato MBR tradizionale.
Come ispezionare in sicurezza un collettore GPT
Per un'analisi approfondita, utilizzare un'immagine disco o un visualizzatore esadecimale con accesso in sola lettura.
- Verificare che il disco fisico sia quello corretto e che la dimensione del blocco logico riportata sia quella corretta.
- Se il disco contiene dati importanti, creare un’immagine adeguata prima di modificare qualsiasi metadato. Un disco instabile o difettoso richiede un approccio di acquisizione adeguato.
- Apri l'immagine in un editor esadecimale senza abilitare le operazioni di scrittura.
- Individuare l'intestazione primaria all'LBA
1, corrispondente all'offset in byteLogicalBlockSize × 1. - Controlla la firma all'offset
0x00e interpretare gli altri campi utilizzando gli offset relativi all'intestazione. - Calcolare l'ultimo LBA in base alla dimensione dell'immagine o alla capacità del disco, quindi controllare l'intestazione del backup.
- Confronta i valori dei campi, i checksum delle intestazioni e gli array delle voci di partizione associati.
Gestione disco di Windows e PowerShell Get-Disk sono in grado di identificare lo stile di partizione del disco, ma le loro normali schermate di riepilogo non forniscono una verifica completa dell'intestazione GPT a livello di byte.
Non inizializzare, formattare né eseguire DiskPart pulire semplicemente perché un disco segnala una partizione non valida o mancante. Allo stesso modo, CHKDSK è uno strumento di riparazione del file system, non un metodo generico per la ricostruzione dell'intestazione GPT.
Limiti e casi limite importanti
Diversi fattori influenzano l'interpretazione dell'intestazione GPT.
Dimensioni dei blocchi logici diverse. Un disco da 4Kn utilizza blocchi logici da 4.096 byte. L'intestazione primaria rimane all'LBA 1, ma il suo offset assoluto in byte differisce da quello presente su un disco con settori logici da 512 byte.
Intestazioni GPT più grandi. Un'intestazione può superare i 92 byte entro i limiti della dimensione logica del blocco consentita. Il CRC32 deve utilizzare il valore effettivo convalidato Dimensione intestazione, non una costante ipotetica.
Ridimensionamento o clonazione del disco. Se un disco viene ampliato, l'intestazione del backup precedente potrebbe non trovarsi più all'LBA finale. Prima di apportare correzioni, è necessario verificare i metadati GPT in base alle dimensioni attuali del dispositivo.
CRC32 non è un metodo di autenticazione crittografica. Il fatto che i checksum corrispondano non dimostra che i metadati siano autentici o privi di manipolazioni intenzionali.
Problemi relativi ai supporti fisici. Errori di lettura, connessioni intermittenti o guasti del controller possono impedire un’ispezione affidabile. Tentativi ripetuti su hardware difettoso potrebbero rendere più difficile il ripristino.
Queste limitazioni spiegano perché la convalida GPT richieda diverse verifiche correlate anziché un unico confronto tra firme o checksum.
Conclusione
Il Intestazione GPT fornisce le informazioni relative alla posizione, ai confini, agli identificatori e all'integrità necessarie per interpretare una tabella delle partizioni GUID. La sua struttura è definita da offset di byte espliciti, e le sue copie primaria e di backup forniscono metadati ridondanti alle estremità opposte di un disco.
Per effettuare un'analisi corretta non basta limitarsi a individuare EFI PARTE. Il CRC32 dell'intestazione, il CRC32 dell'array delle voci di partizione, i puntatori LBA, i confini utilizzabili e la coerenza tra partizione primaria e di backup devono essere valutati congiuntamente.
Comprendere queste relazioni consente di riconoscere i metadati GPT validi, individuare le incongruenze e distinguere il danneggiamento della tabella delle partizioni dall'effettiva perdita dei dati dei file.
FAQ
Che cos’è la firma dell’intestazione GPT?
EFI PARTE. In esadecimale, è 45 46 49 20 50 41 52 54. Appare all'inizio sia dell'intestazione primaria che di quella di backup. Il solo rilevamento di questa sequenza non garantisce che l'intero GPT sia valido.Quanti byte ha un’intestazione GPT?
Dimensione intestazione Il campo definisce la sua lunghezza effettiva, che deve essere di almeno 92 byte e non superiore alla dimensione del blocco logico. I byte rimanenti del blocco logico sono riservati.Dove sono memorizzate le intestazioni GPT primarie e di backup?
1. L'intestazione di backup è memorizzata nell'ultimo blocco logico del disco. Ogni intestazione MyLBA identifica la propria posizione, mentre AlternateLBA identifica l'altra intestazione.Perché le intestazioni GPT primaria e di backup presentano valori CRC32 diversi?
MyLBA, AlternateLBA, e di solito PartitionEntryLBA. Poiché questi byte sono inclusi nell'HeaderCRC32, i checksum calcolati risulteranno generalmente diversi anche quando entrambe le intestazioni descrivono accuratamente lo stesso disco.Un header GPT può superare la verifica CRC32 anche se il disco è danneggiato?
È possibile recuperare un'intestazione GPT danneggiata dal backup?
Il GUID del disco GPT è uguale al GUID di una partizione?
DiskGUID Il campo nell'intestazione GPT identifica il disco. Le singole voci di partizione contengono identificatori distinti, tra cui un GUID del tipo di partizione e un GUID univoco della partizione. Questi valori hanno ruoli diversi e non devono essere confusi.