Wiederherstellen von ext4-Superblöcken

47

Vor kurzem ist mein externes Festplattengehäuse ausgefallen (die Festplatte selbst wird in einem anderen Gehäuse hochgefahren). Infolgedessen scheint das EXT4-Dateisystem jedoch beschädigt zu sein.

Das Laufwerk verfügt über eine einzelne Partition und verwendet eine GPT-Partitionstabelle (mit der Bezeichnung ears).

fdisk -l /dev/sdb zeigt an:

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

testdisk Zeigt an, dass die Partition intakt ist:

1 P MS Data                     2049 1953524952 1953522904 [ears]

... aber die Partition kann nicht gemountet werden:

$ 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 meldet einen ungültigen Superblock:

$ 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

und e2fsckmeldet einen ähnlichen Fehler:

$ 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 ebenfalls:

$ 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(Anmerkung, -n) gibt die Superblöcke zurück:

$ 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

... aber der Versuch "e2fsck -b [block]" für jeden Block schlägt fehl:

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

Soweit ich weiß, befanden sich hier die Superblöcke, als das Dateisystem erstellt wurde, was nicht unbedingt bedeutet, dass sie noch intakt sind.


Ich habe auch eine gründliche testdisk Suche durchgeführt, wenn jemand das Protokoll entschlüsseln kann. Es erwähnt viele Einträge wie:

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

Wenn Sie e2fsck mit diesen Werten ausführen, erhalten Sie:

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

Ich habe das mit allen Superblöcken im versucht testdisk.log

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

... alle mit der gleichen e2fsckFehlermeldung.


Bei meinem letzten Versuch habe ich verschiedene Dateisystem-Offsets ausprobiert. iWo iist für jeden Offset einer von 31744, 32768, 1048064, 1049088:

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

... und beim Laufen testdisk /dev/loop0fand ich nichts interessantes.


Ich war ziemlich ausführlich, aber gibt es eine Möglichkeit , das Dateisystem wiederherzustellen, ohne auf einfache Tools zur Wiederherstellung von Dateien ( foremost/ photorec) zurückzugreifen?

tlvince
quelle
Was sudo fdisk -l /dev/sdbzeigt?
Karlson
4
Ich kann mir nicht vorstellen, dass Sie das Pech hatten, alle Kopien des Superblocks gelöscht zu haben. Es muss also ein Fehler in der Partitionstabelle vorliegen, der wiederum die logischen Blockversätze im Dateisystem auslöst und dazu führt, dass fsck die alternativen Superblöcke nicht finden kann.
Kyle Jones
Hatten Sie nicht auf dieser Festplatte LVM? Haben Sie ein externes Gehäuse vom gleichen Typ wie zuvor (gleiche Blockgröße usw.)?
Jan Marek,
1
@KyleJones Auf Empfehlung des Autors von habe testdiskich, wie oben erwähnt, verschiedene Offsets ausprobiert losetup( i * 512wobei ieiner von 62, 64, 2047 oder 2049 ist).
seit dem
@ JanMarek Nein, leider kein LVM. Das Gehäuse ist eines, das eine Standard-3,5-
Zoll-

Antworten:

15

Leider konnte ich das Dateisystem nicht wiederherstellen und musste auf niedrigere Datenwiederherstellungstechniken zurückgreifen (schön zusammengefasst in Ubuntus Data Recovery- Wiki-Eintrag), von denen sich Sleuth Kit als am nützlichsten erwies.

Kennzeichnung aus Gründen der Sauberkeit als beantwortet.

tlvince
quelle
8

Dies mag schon veraltet sein, aber ein paar Vorschläge:

Wenn Sie absolut sicher sind, dass die ursprüngliche Blockgröße 4096 ist testdisk, können Sie die Superblöcke auf der Festplatte mithilfe von überschreiben mke2fs -S. Vom Menschen:

   -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.

Wenn Sie sich über die korrekte Blockgröße nicht sicher sind, verwenden Sie mke2fs -n -b 2048 /dev/sdb1alle Superblock-Sicherungen, die dieser Befehl liefert, und versuchen Sie es erneut. Danach verwenden Sie die letzte Blockgröße 1024.

Jari Laamanen
quelle
0

Wie bereits erwähnt, wahrscheinlich veraltet, aber fdisk (AFAIK) unterstützt keine GPT-Festplatten. Sie müssen parted oder ein anderes Tool verwenden.

Ich habe gerade eine virtuelle Maschine getestet, auf der Debian Squeeze (Kernel 2.6.32-5-486) ​​läuft, und eine virtuelle Festplatte als GPT formatiert, indem ich ...

# 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

Dies ist die fdisk Version 2.17.2 (util-linux-ng).

mkfs und fsck sollten die 'echte' Partition aufnehmen, aber um zu überprüfen, dass die GPT-Partitionstabelle nicht beschädigt ist, sollten Sie GNU Parted verwenden.

StarNamer
quelle
0

Ich habe nach dem Neustart meines Computers das gleiche Montageproblem. In meinem Fall war es ausreichend, getrennt zu laufen und einen Befehl wie den folgenden auszugeben:

set 1 lvm on

und dann beenden und versuchen, erneut zu montieren. Vielleicht hilft es dir auch.

user30192
quelle