Ricostruire l’MBR dopo averlo accidentalmente sovrascritto

tl;dr fdisk. E pregare di ricordarsi posizione e dimensioni di tutte le partizioni.

Non so come, qualche programma è andato contro la mia volontà e contro le indicazioni che esso stesso dava e contro le sue stesse capacità e mi ha devastato la tabella delle partizioni e qualche altro kilobyte di dati su un disco rigido.
Ma partiamo dall’inizio…

Il disastro

Avevo necessità di creare un floppy con HDT per identificare l’hardware di un pc del 1998.

Avendo un lettore floppy esterno, l’ho collegato al mio usuale pc, ci ho sbattuto dentro un floppy e ho cercato di scriverci sopra il file .img di HDT.
Win32 Disk Imager si piantava immediatamente con un errore che mi pare fosse “accesso negato”: ormai sono abituato a questo genere di errori assolutamente non esplicativi che dipendono da qualche programma che sta maneggiando il file o in questo caso il floppy, non me ne preoccupo.

Visto che Win32 Disk Imager non ne vuole sapere, ritrovo nei meandri del pc RawWrite, ho il vago ricordo di averlo usato l’ultima volta due anni fa sempre per scrivere un’immagine su un floppy, bene, forse ce la farà.

E infatti al primo colpo scrive.

Ora, su entrambi i programmi avevo controllato 20 volte che fosse selezionato A:, il lettore floppy era senza ombra di dubbio alcuno A:, nessuno dei due programmi mi mostrava nemmeno C: o S: (il disco secondario. S per Storage…). Giusto per chiarire.

Tutto bene, tutto bello, tutto funziona, i lettori floppy fanno i loro temibili rumori, identifico l’hardware e la cosa finisce lì.

Al successivo riavvio del mio pc, iniziano a partire messaggi d’errore di ogni genere da programmi presi dal panico, ma nessuno riesce a dirmi chiaramente cosa sta succedendo: dopo aver calmato tutti i programmi, vado su risorse del computer e vedo che S: ora si chiama E:.
E ha l’etichetta del floppy di HDT.
E dentro c’è HDT.
E basta.
Ed è formattato in FAT16.

Non mi pare il caso di ripristinare i backup, visto che dovrei recuperare tutto da due dischi esterni separati e poi da SpiderOak e poi ultimamente ho spostato un po’ di file in giro ma non ho aggiornato i backup sui dischi esterni. Quindi, leggermente preoccupato, spengo e inizio a pensare al da farsi.

Disaster recovery, tentativo 1

Ho sempre il CD con RIPLinuX del 2011, che già una volta mi ha salvato, provo con quello.

Avvio, apro GNU cfdisk (sul CD c’è anche la versione non-GNU) anch’essa risalente al 2011, ma tanto devo solo ricostruire la tabella delle partizioni di un disco MBR, non c’è nemmeno GPT di mezzo, cosa può andare storto?

Va storto che cfdisk crea la partizione NTFS, chiede conferma per scrivere, confermo, conferma di aver scritto e se vado a leggere la tabella con qualsiasi altro programma, incluso cfdisk, c’è di nuovo la partizione FAT16.

Il cfdisk non-GNU spara un messaggio d’errore e non mi mostra nemmeno le partizioni.

GParted cerca di farmi capire che se voglio impostare quella partizione (che tutti i programmi finora continuano a vedere come grande 1 TB) come NTFS, devo anche obbligatoriamente e irrevocabilmente formattarla, perché cambiare quei pochi bit nella tabella delle partizioni senza fare altro è evidentemente troppo difficile…

Disaster recovery, tentativo 2

Avvio Arch.

Schermata nera.

Avvio Arch come “UEFI” e non “legacy”.

Schermata nera.

Page fault.

Parte.

Ehm, ok, almeno è partito.

Invoco fdisk, che legge dalla tabella 4 partizioni di cui una exFAT, una NTFS, una ignota e una non mi ricordo, che sommate occupano più di 1 TB, con settori di inizio e fine casuali, e disallineate. È chiaro che… beh, no, non è chiaro un bel niente. Se questi sono dati binari parte di HDT che vengono letti come tabella delle partizioni, come mai prima Windows, i due cfdisk e GParted vedevano una partizione FAT16 solitaria che qui nemmeno esiste? Uhm…

Desisto dal farmi domande, cancello tutto, ricreo la partizione con dimensioni di default, la imposto come NTFS, prego che le dimensioni siano uguali a com’erano prima e la MFT non sia maciullata oltre ogni possibilità di recupero e scrivo la nuova tabella.

Prima di avviare Windows, proviamo un po’ a fare…
mount /dev/sda1 /mnt/asd -o ro
ls /mnt/asd

Eeeeeeeee… i file sembrano esserci tutti. Tiro un sospiro di sollievo: almeno la dimensione era giusta e la MFT non è perduta per sempre.

Avvio Windows. Per Windows è tutto a posto, regolare, perfetto. Il disco si chiama ancora E: ma ci vogliono due secondi a rinominarlo in S:. Per scrupolo faccio un chkdsk infinito che non trova nulla di anomalo.

L’allineamento mi ha salvato. Forse.

Mentre il chkdsk infinito andava, mi sono documentato sulla struttura della MFT NTFS, dell’MBR e dei floppy.

L’immagine era grande 1.44 MiB, fdisk ha allineato l’inizio della partizione su 2048 settori e tutto ha funzionato quindi anche prima era così; visto che i settori sono da 4 KB (o kB se vogliamo fare i perfezionisti, o kilobyte perché adesso l’ho scritto senza il numero di fianco e nel SI non si può scrivere la sigla dell’unità senza la quantità e bisognerebbe scriverla per intero e devo smetterla di divagare sul SI…), visto che i settori indicati da fdisk in realtà sono da 512 byte altrimenti tutti su internet stanno mentendo, c’era un 1 MiB di vuoto prima della prima partizione.

Da qualche parte c’era l’MBR. A intuito sembrerebbe stare in quel vuoto. Quindi l’immagine del floppy ci è finita sopra, poi ha sovrascritto 0.44 MiB di dati nella partizione NTFS: all’inizio ci sono 512 byte con dati non proprio trascurabili, quali la posizione della MFT e il bootloader (che non c’era, immagino, su quella partizione che non è di boot…), poi la MFT stessa i cui primi 4 KiB (o kB?) esistono anche in un’altra copia, per sicurezza.

Quindi si dovrebbero essere persi dei dati essenziali della partizione. Credo che fdisk abbia modificato solo la tabella e non abbia sovrascritto i 512 byte iniziali delle partizioni NTFS, quindi da dove sono riapparsi? O non sono mai stati sovrascritti? Ma allora quegli 0.44 MiB dove sono andati?

Beh, in ogni caso, l’1 MB di vuoto, o di MBR che tanto si ricostruisce facilmente, mi ha salvato dalla perdita irreparabile di un pezzo di MFT. Credo. Non si capisce nulla.

And the moral of this story is… You can’t trust the system!

Il sistema dei backup totali fatti solo ogni tanto, si intende. Bisogna farli continuamente. Se avessi ripristinato all’istante da un backup ci avrei messo meno, ma il backup deve essere una copia 1:1 del contenuto del disco (perché, diciamocelo, chi ha spazio per un backup incrementale? Come, tutti? Ehm, ok…) altrimenti, se qualcosa pialla la MFT, anche il backup è perduto. O si fa incrementale.

Annunci

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...