Восстановление ext4 суперблоков

47

Недавно мой внешний корпус жесткого диска вышел из строя (сам жесткий диск включается в другом корпусе). Тем не менее, в результате оказывается, что его файловая система EXT4 повреждена.

Диск имеет один раздел и использует таблицу разделов GPT (с меткой ears).

fdisk -l /dev/sdb шоу:

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

testdisk показывает, что раздел не поврежден:

1 P MS Data                     2049 1953524952 1953522904 [ears]

... но раздел не удается смонтировать:

$ 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 сообщает о неверном суперблоке:

$ 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

и e2fsckсообщает об аналогичной ошибке:

$ 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 также:

$ 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(примечание, -n) возвращает суперблоки:

$ 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

... но попытка "e2fsck -b [block]" для каждого блока не удалась:

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

Однако, как я понимаю, именно там были суперблоки, когда создавалась файловая система, что не обязательно означает, что они все еще не повреждены.


Я также провел testdisk глубокий поиск, если кто-нибудь может расшифровать журнал. Упоминается много записей, как:

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

Запуск e2fsck с этими значениями дает:

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

Я попробовал это со всеми суперблоками в testdisk.log

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

... все с тем же e2fsckсообщением об ошибке.


В моей последней попытке я пробовал разные смещения файловой системы. Для каждого смещения i, где iодин из 31744, 32768, 1048064, 1049088:

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

... и бегу testdisk /dev/loop0, я не нашел ничего интересного.


Я был довольно исчерпывающим, но есть ли способ восстановить файловую систему, не прибегая к низкоуровневым инструментам восстановления файлов ( foremost/ photorec)?

tlvince
источник
Что sudo fdisk -l /dev/sdbпоказывает?
Карлсон
4
Я не могу заставить себя поверить, что вам не повезло, что вы удалили все копии суперблока. Таким образом, должно быть что-то не так с таблицей разделов, которая в свою очередь отбрасывает смещения логических блоков в файловой системе, что приводит к тому, что fsck не может найти альтернативные суперблоки.
Кайл Джонс
Разве у вас не было на этом диске LVM? У вас есть внешний корпус того же типа, что и предыдущий (такой же размер блока и т. Д.)?
Ян Марек
1
@KyleJones Следуя совету автора testdisk, как упоминалось выше, я пробовал разные смещения с помощью losetup( i * 512где iодин из 62, 64, 2047 или 2049).
tlvince
@JanMarek Нет, к сожалению, нет LVM. В корпусе находится любой стандартный 3,5-
дюймовый

Ответы:

15

К сожалению, мне не удалось восстановить файловую систему, и мне пришлось прибегнуть к более низкоуровневым методам восстановления данных (хорошо изложенным в вики-статье Ubuntu для восстановления данных ), из которых Sleuth Kit оказался наиболее полезным.

Маркировка как отвеченная ради чистоты.

tlvince
источник
8

Это может быть уже устаревшим, но несколько предложений:

Если вы абсолютно уверены, что исходный размер блока составляет 4096, как утверждается testdisk, вы можете перезаписать суперблоки на диске, используя mke2fs -S. От мужчины:

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

Если вы не уверены в правильности размера блока, используйте mke2fs -n -b 2048 /dev/sdb1и попробуйте все резервные копии суперблоков, которые дает эта команда, и после этого то же самое, но с использованием последнего размера блока 1024.

Яри ​​Лааманен
источник
0

Как уже упоминалось, возможно, устарел, но fdisk (AFAIK) не поддерживает GPT-диски. Вам нужно использовать parted или какой-то другой инструмент.

Я только что проверил виртуальную машину с Debian squeeze (ядро 2.6.32-5-486) ​​и отформатировал виртуальный диск как GPT, используя 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

Это fdisk версии 2.17.2 (util-linux-ng).

mkfs и fsck должны выбрать «настоящий» раздел ОК, но чтобы проверить, не повреждена ли таблица разделов GPT, вы должны были использовать GNU parted.

StarNamer
источник
0

У меня возникла такая же проблема с установкой после перезагрузки компьютера. В моем случае этого было достаточно, чтобы запустить parted и выполнить команду вроде:

set 1 lvm on

а затем выйдите и попробуйте перемонтировать. Может быть, это поможет вам тоже.

user30192
источник