recupero partizione ext4 dopo aver iniziato all'inizio dell'HD

Ho accidentalmente usato dde scritto sui primi 208 MB del mio disco esterno. Quello su cui ho scritto è una partizione a sé stante (Debian nestinstaller) quindi quello che vedo ora non è la mia vecchia partizione ext4 (ora danneggiata) ma un'altra partizione più piccola. Ciò limita gli strumenti e i consigli che potrei seguire.

Il mio piano era di ricreare la tabella delle partizioni con testdiske quindi riparare tutto con i superblocchi di backup come descritto qui . Perderei i primi 208 MB, ma va bene rispetto agli altri 300 GB di dati. Qualcosa di simile al seguente:

mke2fs -n /dev/sdb1   # doesn't work because sdb1 is the 208MB new partition
testdisk ...          # used this to create new correct partition table
mke2fs -n /dev/sdb1   # now works fine, get backup superblock positions
e2fsck -b backup_position -y /dev/sdb1 # returns many errors hence the -y

Tuttavia, non sono stato in grado di recuperare nulla. Ho usato testdiskper scrivere una nuova tabella delle partizioni che abbinato quello che avevo prima. Quando eseguo e2fsck ottengo molti errori diversi. Dopo di ciò ottengo un filesystem ma è completamente vuoto, nessun file.

La directory lost + found è piena di file (penso di quelli recuperati) ma devo recuperare l'albero delle directory, non solo i file. Ho bisogno del nome del file e delle directory precedenti per sapere quali sono i file (immagini al microscopio, dati di specifiche di massa, ecc. Senza i nomi e le directory in cui si trovavano, non significano nulla).

Ho ottenuto un altro HD esattamente lo stesso e ho fatto una copia dell'intero HD in ddmodo da poter sperimentare il recupero senza perdere nulla. Qualche consiglio?

Finalmente sono riuscito a risolvere questo problema. Solo per la cronaca, ecco come l'ho fatto. Parte della soluzione che ho trovato qui e comporta la conoscenza delle impostazioni utilizzate per creare il filesystem (ero abbastanza sicuro di non aver modificato le impostazioni predefinite).

Fondamentalmente ho dovuto prima riparare la tabella delle partizioni per riflettere ciò che effettivamente avevo lì (ho usato testdiskper questo ma parted, cfdisko fdiskdovrei anche funzionare bene). Ho appena rimosso le partizioni sbagliate e sostituite da una singola partizione di tipo ext4 che copre l'intero disco con i valori CHS corretti.

Il resto proviene principalmente dal link all'avvio (leggilo per i dettagli) ma fondamentalmente ho corso mke2fs -n /dev/xxxper trovare le posizioni per il backup dei superblocchi. Quindi ha usato l'ultimo backup più vicino alla fine del disco (solo quelli all'inizio del disco erano stati sovrascritti con dd) per eseguire fsck. Ciò ha generato molti errori ma fsck ha -yun'opzione (non uguale a -a).

$ sudo e2fsck -a -b backup_block_number /dev/xxx

Pensavo che non avesse funzionato perché non riuscivo a vedere alcun file ma in realtà erano stati tutti salvati nella lost+founddirectory.

Quindi alla fine ho recuperato la maggior parte dei miei file mantenendo i nomi dei file e la struttura delle directory. Spero che questo possa aiutare gli altri in futuro.

Ok, questo funziona per il ripristino da un'unità inavvertitamente inserita in un array MegaRAID. Il mio controller RAID ha inserito TUTTE le unità nel RAID, non solo quelle per l'array RAID6 che stavo rifacendo. Ahia! Almeno ho fatto un init rapido, e non un init lento: l'init lento cancella l'unità a zero.

Quick init cancella 10M all'inizio e alla fine delle unità. Quindi, io con una partizione ext4 sull'intero disco (sotto Linux) e un disco, RAID0, ho avuto qualche possibilità. Con l'unità da 6 TB e quasi 5 TB, stavo sudando: era il mio backup dell'array RAID6 che stavo riformando!

A proposito, non sono scivolato - l'LSI MegaRAID NON avrebbe dovuto avviare le unità nell'altro mio gruppo di unità - ma lo ha fatto. Come nota, ciò che avrei dovuto fare è RIMUOVERE L'UNITÀ DALL'INCLOSURE e reimportarlo DOPO che avevo il gruppo di unità RAID6 appena organizzato. Sciocco me Davvero sciocco me ....

OK, fortunatamente LSI MegaRaid non fa nulla di speciale con le unità RAID0 (se ce n'è una non credo ne sia sicura). Ecco cosa ho fatto per risolverlo. OS = Fedora F22. Drive = una grande partizione ext4, terminata con parted. Per prima cosa ho scansionato a scatto l'unità su una nuovissima, esattamente dello stesso modello, in un server di riserva con un paio di slot per alloggiamento di riserva :: Dieci ore dopo è finito ......

$ dd if=/dev/sdb of=/dev/sdc bs=64M conv=notrunc
89424+1 records in
89424+1 records out
6001175126016 bytes (6.0 TB) copied, 35130.2 s, 171 MB/s

Quello era il mio backup d'oro.

NOTA - La mia unità era /dev/sdb: è necessario impostare l'unità su qualsiasi unità che si sta tentando di ripristinare. Non rovinare le unità, o sarai ancora più nel caos ...

Quindi, fatto ciò, ho fatto quanto segue.

(1) rimuovi l'istantanea dalla macchina (non di nuovo sciocco, te lo posso assicurare - se non ci riuscissi saremmo andati all'ospedale di recupero del disco, mentre mi sono registrato nell'ER locale!).

(2) riavviare la macchina FC22 con l'unità. Esegui parted, ripristina la partizione (nel mio caso, elimina quella danneggiata, scrivi in ​​una nuova partizione ext4 dallo 0% al 100%). Devi sapere esattamente dove si trovavano le partizioni originali e il loro tipo esatto - il passo successivo dipende da questo - in caso contrario, FERMATI QUI. Non ce la farai. utilizzare testdiske / photoreco simili, o per un disco grande dove conta davvero, spedirlo.

(3) corri mke2fs -n /dev/sdb1(non dimenticare il -n, o di nuovo puoi semplicemente andartene ...)

Per me il risultato è stato:

$ mke2fs -n /dev/sdb1
$ mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 1464843008 4k blocks and 183107584 inodes
Filesystem UUID: 1ac318a6-7953-42d5-8d7b-0597c54e1935
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

Ecco qua, ecco dove sono tutti i superblocchi di scorta ...... Sappiamo che il primo e l'ultimo sono spazzatura, ma quelli nel mezzo dovrebbero essere OK. (Nota, puoi usare mkfs.ext4 -n /dev/sdb1per essere molto cauto e ottenere lo stesso risultato).

(4) Esegui e2fsck -y -b 102400000 /dev/sdb1. Avrai bisogno di -y, poiché ci sarà un sacco di "sì" necessari per correggere il disordine creato dal front-end mancante del disco .... e scegliere qualsiasi superblocco nel mezzo che ti piace ... e dopo circa 30 minuti di silenzio (usa un altro terminale e "top" per vedere i progressi, o la luce del disco lampeggiante) nel mio caso presto, una partizione montabile, e praticamente tutto intatto nella /lost+founddirectory.

Ad ogni modo spero che questo ti aiuti - se stai leggendo attentamente, ti auguro buona fortuna. E grazie ai ragazzi che scrivono sopra. Mi hai salvato da una fine davvero disgustosa .....