Ripristino dei superblocchi ext4


47

Di recente, il mio hard disk esterno si è guastato (il disco rigido stesso si accende in un altro enclosure). Tuttavia, di conseguenza, sembra che il suo file system EXT4 sia corrotto.

L'unità ha una singola partizione e utilizza una tabella delle partizioni GPT (con l'etichetta ears).

fdisk -l /dev/sdb Spettacoli:

   Device Boot      Start         End      Blocks   Id  System
     /dev/sdb1          1  1953525167   976762583+  ee  GPT

testdisk mostra che la partizione è intatta:

1 P MS Data                     2049 1953524952 1953522904 [ears]

... ma la partizione non riesce a montare:

$ sudo mount /dev/sdb1 a
mount: you must specify the filesystem type
$ sudo mount -t ext4 /dev/sdb1 a 
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,

fsck segnala un superblocco non valido:

$ sudo fsck.ext4 /dev/sdb1            
e2fsck 1.42 (29-Nov-2011)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb1

e e2fscksegnala un errore simile:

$ sudo e2fsck /dev/sdb1        
Password: 
e2fsck 1.42 (29-Nov-2011)
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

dumpe2fs anche:

$ sudo dumpe2fs /dev/sdb1                      
dumpe2fs 1.42 (29-Nov-2011)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1

mke2fs -n(nota, -n) restituisce i superblocchi:

$ sudo mke2fs -n /dev/sdb1       
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
61054976 inodes, 244190363 blocks
12209518 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
7453 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

... ma provare "e2fsck -b [blocco]" per ogni blocco fallisce:

$ sudo e2fsck -b 71663616 /dev/sdb1 
e2fsck 1.42 (29-Nov-2011)
e2fsck: Invalid argument while trying to open /dev/sdb1

Comunque, a quanto ho capito, questi sono i superblocchi al momento della creazione del filesystem, il che non significa necessariamente che siano ancora intatti.


Ho anche eseguito una testdisk ricerca approfondita se qualcuno può decifrare il registro. Menziona molte voci come:

recover_EXT2: s_block_group_nr=1/7452, s_mnt_count=6/20,
s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 244190363
recover_EXT2: part_size 1953522904
recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed

L'esecuzione di e2fsck con questi valori dà:

e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

L'ho provato con tutti i superblocchi in testdisk.log

for i in $(grep e2fsck testdisk.log | uniq | cut -d " " -f 4); do
   sudo e2fsck -b $i -B 4096 /dev/sdb1
done

... tutti con lo stesso e2fsckmessaggio di errore.


Nel mio ultimo tentativo, ho provato diversi offset del filesystem. Per ogni offset i, dove iè uno di 31744, 32768, 1048064, 1049088:

$ sudo losetup -v -o $i /dev/loop0 /dev/sdb

... e correndo testdisk /dev/loop0, non ho trovato nulla di interessante.


Sono stato abbastanza esaustivo, ma c'è un modo per ripristinare il file system senza ricorrere a strumenti di recupero file di basso livello ( foremost/ photorec)?


Cosa sudo fdisk -l /dev/sdbmostra?
Karlson

4
Non riesco a farmi credere che sei stato abbastanza sfortunato da cancellare tutte le copie del superblocco. Quindi ci deve essere qualcosa di sbagliato nella tabella delle partizioni, che a sua volta sta eliminando gli offset del blocco logico nel filesystem, impedendo a fsck di trovare i superblocchi alternativi.
Kyle Jones

Non avevi su questo disco LVM? Hai un contenitore esterno dello stesso tipo del precedente (stessa dimensione del blocco, ecc.)?
Jan Marek,

1
@KyleJones Seguendo i consigli dell'autore testdisk, come menzionato sopra, ho provato diversi offset usando losetup( i * 512dove iè uno dei 62, 64, 2047 o 2049).
dal

@JanMarek No, purtroppo nessun LVM. Il contenitore è uno che ospita qualsiasi disco standard da 3,5 ", ma non ne ho un altro, né un secondo disco da 1 TB.
partire dal

Risposte:


15

Sfortunatamente, non sono stato in grado di ripristinare il file system e ho dovuto ricorrere a tecniche di recupero dei dati di livello inferiore (ben riassunte nella voce wiki di Ubuntu Data Recovery ), di cui Sleuth Kit si è rivelato molto utile.

Contrassegnare come risposto per motivi di pulizia.


8

Questo potrebbe essere già obsoleto, ma alcuni suggerimenti:

Se sei assolutamente sicuro che la dimensione del blocco originale sia 4096, come affermato da testdisk, puoi riscrivere i superblocchi sul disco usando mke2fs -S. Dall'uomo:

   -S    Write  superblock and group descriptors only.  This is useful if all
          of the superblock and backup superblocks are corrupted, and a  last-
          ditch  recovery method is desired.  It causes mke2fs to reinitialize
          the superblock and group descriptors, while not touching  the  inode
          table and the block and inode bitmaps.  The e2fsck program should be
          run immediately after this option is used, and there is no guarantee
          that  any  data  will be salvageable.  It is critical to specify the
          correct filesystem blocksize when using this option, or there is  no
          chance of recovery.

Se non si è sicuri della dimensione del blocco corretta, utilizzare mke2fs -n -b 2048 /dev/sdb1e provare tutti i backup del superblocco forniti da questo comando, e successivamente lo stesso ma utilizzando l'ultima dimensione del blocco 1024.


0

Come accennato, probabilmente obsoleto, ma fdisk (AFAIK) non supporta i dischi GPT. Devi usare parted o qualche altro strumento.

Ho appena testato una macchina virtuale con Debian squeeze (kernel 2.6.32-5-486) ​​e formattato un disco virtuale come GPT usando parted ...

# parted /dev/sde
(parted) mklabel GPT
(parted) mkpart part1 0 10G
(parted) quit
# fdisk -l /dev/sde
.
WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.
.
Disk /dev/sde: 85.9 GB, 85899345920 bytes
 255 heads, 63 sectors/track, 10443 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
. 
   Device Boot      Start         End      Blocks   Id  System
/dev/sde1               1       10444    83886079+  ee  GPT

Questa è fdisk versione 2.17.2 (util-linux-ng).

mkfs e fsck dovrebbero selezionare OK la partizione "reale", ma per verificare che la tabella delle partizioni GPT non sia danneggiata, si dovrebbe usare GNU parted.


0

Ho avuto lo stesso problema di montaggio dopo aver riavviato il mio computer. Nel mio caso è stato sufficiente eseguire parted ed emettere un comando come:

set 1 lvm on

quindi esci e prova a rimontare. Forse ti aiuterà anche.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.