На моем сервере произошел какой-то сбой диска, из-за которого ОС (CentOS 5) вылетела и перестала работать (она отказывается загружаться).
Итак, мы ставим другой диск с работающей ОС и оттуда пытаемся смонтировать разделы на старом диске.
Большинство разделов монтируются нормально, за исключением одного: /var раздел, где находятся мои таблицы MySQL.
Когда я пытаюсь его смонтировать, я вижу эти ошибки с dmesg:
sd 0: 0: 1: 0: Необработанный сенсорный код
sd 0: 0: 1: 0: ошибка SCSI: код возврата = 0x08100002
Результат: hostbyte = недопустимый driverbyte = DRIVER_SENSE, SUGGEST_OK
sdb: Current: сенсорный ключ: средняя ошибка
Добавить. Смысл: невосстановленная ошибка чтенияИнформация fld = 0x4a47e
JBD: не удалось прочитать блок по смещению 9863
JBD: восстановление не удалось
EXT3-fs: ошибка загрузки журнала.
Есть ли способ восстановить данные в этом разделе?
РЕДАКТИРОВАТЬ:
Согласно запросу, вывод tune2fs -l /dev/sdb2 является:
tune2fs 1.39 (29-May-2006)
Filesystem volume name: /var1
Last mounted on: <not available>
Filesystem UUID: d84f5181-24f3-40ce-9eaa-601ae5ae33bd
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 26214400
Block count: 26214063
Reserved block count: 1310703
Free blocks: 25127226
Free inodes: 26213665
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1017
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 32768
Inode blocks per group: 1024
Filesystem created: Thu May 13 18:14:28 2010
Last mount time: Thu Nov 29 12:52:00 2012
Last write time: Wed Mar 27 20:29:28 2013
Mount count: 15
Maximum mount count: -1
Last checked: Thu May 13 18:14:28 2010
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 35f38c48-3933-4c99-bde2-63b0eccf200d
Journal backup: inode blocks
РЕДАКТИРОВАТЬ 2:
Как предложил @Hartmut, я бегу fsck.ext3 /dev/sdb2 со следующим результатом:
e2fsck 1.39 (29-May-2006)
/var1: recovering journal
/var1: Attempt to read block from filesystem resulted in short read while reading block 11931
JBD: Failed to read block at offset 9863
fsck.ext3: No such device or address while trying to re-open /var1
e2fsck: io manager magic bad!
Похоже, что на вашем жестком диске произошел физический сбой, и это повлияло на блок, содержащий журнал ext3.
Вам понадобится второй чистый жесткий диск, по крайней мере, такого же размера, как неисправный раздел диска, чтобы выполнить какое-либо восстановление этого диска. Вам также понадобится место назначения для копирования восстановленных файлов, поэтому назовем его третьим пустым жестким диском, сетевым файловым ресурсом и т. Д.
Общий процесс восстановления будет следующим:
Скопируйте неисправный раздел на новый диск, используя dd conv=noerror или лучше dd_rescue. Это может занять некоторое время.
Выполните все дальнейшие операции с копией Здесь я предполагаю, что вы скопировали /dev/sdb2 к /dev/sdc2 и что вы восстановите файлы на /dev/sdd2.
Поскольку журнал поврежден, мы удалим его:
tune2fs -O ^has_journal /dev/sdc2
Теперь завершите fsck устройства. Это может занять некоторое время.
e2fsck /dev/sdc2
Смонтируйте файловую систему в режиме только для чтения и попытайтесь восстановить файлы.
mount -o ro /dev/sdc2 /mnt/baddrive
mount /dev/sdd2 /mnt/recoveredfiles
cp -av /mnt/baddrive/* /mnt/recoveredfiles
Ни в коем случае нельзя снова использовать исходный диск. Замените его (по гарантии, если еще на гарантии).
Вы пытались установить его как файловую систему ext2 с помощью mount -t ext2 ... ? ext3 обратно совместим с ext2, поэтому он должен просто игнорировать журнал, который кажется сломанным. Это не идеальное решение, но оно может позволить вам получить доступ к некоторым данным, если вам повезет!
Возможно, были повреждены суперблоки файловых систем. вы можете выполнить следующие шаги, чтобы восстановить суперблоки.
# dumpe2fs /dev/sdb2 | grep -i superblock
Пример вывода:
Primary superblock at 0, Group descriptors at 1-6
Backup superblock at 32768, Group descriptors at 32769-32774
Backup superblock at 98304, Group descriptors at 98305-98310
Backup superblock at 163840, Group descriptors at 163841-163846
Backup superblock at 229376, Group descriptors at 229377-229382
Либо вы можете fsck раздела с альтернативным суперблоком, либо вы можете смонтировать раздел с альтернативным суперблоком без fsck в файловой системе.
Чтобы проверить файловую систему
# fsck.ext3 -b 32768 /dev/sda2
Чтобы смонтировать файловую систему с альтернативным суперблоком:
# mount sb={alternative-superblock} /dev/device /mnt
# mount sb=32768 /dev/sdb2 /mnt
и попробуйте просмотреть файлы.