Недавно у меня возникли проблемы с AWS в Ирландии, я потерял том, и мне нужно попытаться восстановить.
Я прикрепил проблемный том к / dev / sdf -
Я совершенно новичок в этом, не совсем уверен, что происходит, но это не выглядит многообещающим >>
> sudo fsck /dev/sdf
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdf
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193
При запуске fdisk -l / dev / sdf ... я получаю >>
sudo fdisk -l /dev/sdf Disk /dev/sdf: 8589 MB, 8589934592 bytes 255 heads, 63 sectors/track, 1044 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 Disk /dev/sdf doesn't contain a valid partition table
дополнительная информация После запуска:
> sudo mke2fs -n /dev/sdf Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Может кто-нибудь оказать помощь, мало опыта работы с fsck.
Заранее спасибо!
РЕДАКТИРОВАТЬ >> Нашел ответ:
> sudo mount -t xfs -o /dev/sdf /mnt/test-ebs XFS: Filesystem sdk has duplicate UUID - can't mount
> sudo mount -t xfs -o nouuid /dev/sdf /mnt/test-ebs mount: Structure needs cleaning
> sudo xfs_repair -L /dev/sdf .. . connected inode 9625284, moving to lost+found disconnected inode 9625285, moving to lost+found disconnected inode 9625286, moving to lost+found disconnected inode 9625287, moving to lost+found disconnected inode 17957583, moving to lost+found disconnected dir inode 17977810, moving to lost+found disconnected dir inode 17977835, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 368465 nlinks from 2 to 4 resetting inode 17977810 nlinks from 0 to 2 ..
Затем я снова запустил это sudo mount -t xfs -o nouuid / dev / sdf / mnt / test-ebs
Все работает сейчас!
Ура
Прежде чем запускать fsck, создайте образ файловой системы и работайте с ним. Так что если что-то пойдет не так, у вас будет оригинал. Не работайте с самой файловой системой.
Кроме того, маловероятно, что sdf - это файловая система, sdf - это сам диск, а файловая система находится на каком-то разделе на нем. Запустите fdisk -l / dev / sdf, чтобы увидеть разделы, попробуйте fsck на / dev / sda1 и т. Д.
Чтобы подготовить образ устройства:
# dd if=/dev/sdfX of=sdfX.img
где X - номер раздела, указанный с помощью fdisk -l.
Затем запустите fsck для изображения: EDIT: (обратите внимание, вы не можете использовать fsck напрямую, вместо этого вам нужно указать fsck, какой тип файловой системы это)
# fsck.ext3 sdfX.img
После того, как fsck исправит раздел, смонтируйте его следующим образом:
# mount -o loop sdfX.img /mnt/somedir
Согласно вашему комментарию, fdisk не перечисляет разделы - это может означать, что таблица разделов также потеряна.
Опять же, сделайте образ всего устройства, затем:
# dd if=/dev/sdf of=sdf.img
Тогда попробуйте использовать тестовый диск на образе, чтобы попытаться восстановить таблицу разделов.
Другой вариант - использовать Photorec на изображении. Это очень хороший инструмент, который умеет обнаруживать и находить файлы, даже если файловая система повреждена. Он может восстанавливать множество форматов файлов. По крайней мере, вы сможете получить свои данные.