Диск Ext3 не будет монтироваться после сбоя питания; как восстановить файлы?

Question

После недавнего сбоя питания, из-за которого мой linux box (Ubuntu 8.10) быстро выключился дважды из нормального рабочего состояния, у меня есть диск, который не будет монтироваться.

ОБНОВЛЕНИЕ: диск иногда монтируется, но отображается как совершенно пустой (даже не потерянный + найденный) и показывает 14,9 ГБ свободного места (это диск на 500 ГБ). Когда я пытаюсь что-либо сделать, он выдает ошибку разрешения, и диск отключается. (или, возможно, не был действительно установлен в первую очередь?)

Вот сообщение об ошибке, когда я пытаюсь смонтировать:

~$ sudo mount -a
mount: wrong fs type, bad option, bad superblock on /dev/sdd1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Так, может быть, укажите тип фс?

~$ sudo mount -t ext3 /dev/sdd1 /media/disk-7
mount: wrong fs type, bad option, bad superblock on /dev/sdd1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Нет же Так что-то напутало?

~$ sudo fsck /dev/sdd1
fsck 1.41.3 (12-Oct-2008)
e2fsck 1.41.3 (12-Oct-2008)
/dev/sdd1: recovering journal
fsck.ext3: No such file or directory while trying to re-open /dev/sdd1
Warning... fsck.ext3 for device /dev/sdd1 exited with signal 11.

Поиск по сигналу 11 не был обнадеживающим, но я нашел несколько других способов восстановить диск:

~$ sudo e2fsck /dev/sdd1
e2fsck 1.41.3 (12-Oct-2008)
/dev/sdd1: recovering journal
e2fsck: No such file or directory while trying to open /dev/sdd1

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 [device] 

Все еще надеясь, что этот сбой как-то связан с отключением питания, я предполагаю, что суперблок поврежден или что-то в этом роде, и попробуйте другой: (Сначала я определяю, что мой размер блока составляет 32 КБ, используя makefs -n)

~$ sudo e2fsck -b 32768 /dev/sdd1
e2fsck 1.41.3 (12-Oct-2008)
ext3 recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/sdd1: recovering journal
e2fsck: Journal must be at least 1024 blocks while recovering 
ext3 journal of /dev/sdd1

За Avery Payne ниже я попробовал следующее:

sudo mount -t ext2 -o ro /dev/sdd1 /media/disk-7

Но получил это сообщение об ошибке:

mount: wrong fs type, bad option, bad superblock on /dev/sdd1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so
~$ dmesg | tail
[261157.639721] EXT2-fs: sdd1: couldn't mount because of unsupported optional features (4).

И вот где я застрял. Я пробовал каждый из перечисленных резервных суперблоков и получал тот же результат. Если это поможет, шаг "восстановление журнала" займет много времени, прежде чем он перейдет к тому, чтобы сказать мне, что он не работает.

Честно говоря, меня не волнует возвращение состояния диска за несколько минут до сбоя, а только восстановление 400+ ГБ других данных, которые находятся на нем. Если кто-нибудь знает что-нибудь еще, что я могу попробовать, утилиты или методы восстановления данных ext3, и т.д., я был бы очень признателен!

Answer 1

Проблемы, с которыми вы сталкиваетесь, звучат гораздо более масштабно, чем то, что я ожидал бы от простой потери мощности (даже во время довольно интенсивной записи) на устройстве. Я должен задаться вопросом, действительно ли у вас больше проблем на уровне интерфейса / драйвера, или повреждена таблица разделов или что-то в этом роде.

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

Я не знаю, сможем ли мы помочь с этим делом, но пока не сдавайтесь.

В будущем я бы предложил вам изучить следующую технику:

Когда у вас возникают проблемы с диском в Linux или UNIX, вы обычно можете использовать dd для создания побитовой копии всего устройства в другом месте. Найдите диск, который по крайней мере такой же большой, как рассматриваемый, и попробуйте команду типа: dd if=$PROBLEMATIC of=$TARGET bs=4M ... будьте очень осторожны с if (входной файл) и of (выходной файл) директивы. Оставь это беги. Хорошей идеей будет запустить tail -f /var/log/messages & (или возможный вариант, соответствующий вашему /etc/syslog.conf) ... или сделать это в фоновом режиме или в другом окне. Существуют улучшенные версии dd которые могут более надежно обрабатывать повторы и проходить через плохие блоки (sdd - это имя, которое приходит на ум). Но попробуйте сначала использовать стандартную команду GNU dd .

Вы можете сделать такую копию всего устройства (например, /dev /sdd) или только раздела (/dev /sdd1). Если вы получаете «короткое чтение или подобные ошибки», это говорит о том, что либо у устройства есть физические ошибки, препятствующие чтению через определенные цилиндры, либо, в случае раздела, что таблица разделов искажена каким-либо образом. Вы даже можете сделать два разных изображения dd ... по одному.

Вот хитрость: делайте все ваши попытки fsck и mount и используйте различные другие инструменты восстановления, такие как TCT (The Coroner's Toolkit), для скопированного образа!

Это сводит к минимуму время, затрачиваемое на работу накопителя (которое, возможно, ухудшается на аппаратном уровне при его эксплуатации), и сводит к минимуму влияние неудачных и, возможно, ошибочных попыток восстановления. (В некоторых ситуациях вы создаете одно изображение, затем другое, основываясь на этом, и всегда работаете с третичным изображением ... зависит от того, сколько стоят данные).

Я лично предлагаю вам запустить что-то вроде hexdump или strings чтобы прочитать изображение ... просто дайте ему долго пролистывать и ищите простой текст, который выглядит так, как будто это фрагменты ваших данных. Я использовал grep для восстановления полезных (текстовых) данных из полностью искаженных файловых систем. В случае, если я не предлагаю это как героику восстановления данных ... но как проверку здравомыслия. Если вы прокручиваете десятки мегабайт или несколько гигабайт данных и не видите какой-либо узнаваемый текст ... тогда у вас, вероятно, безнадежный случай, или вы сделали что-то очень неправильное (действительно ли вы были осторожны с этим, если = и = варианты?).

Я не знаю, поможет ли что-нибудь из этого в текущем усилии. Но изучите эти приемы сейчас, и они определенно сделают ваш следующий шаг в восстановлении данных гораздо менее пугающим. (Да, попрактикуйтесь на здоровой системе один или два раза - используйте шестнадцатеричный редактор и попробуйте добавить свое творческое искажение тут и там - конечно, в КОПИЮ! Тогда попробуйте это исправить).

О, и это действительно хорошее время, чтобы пересмотреть свои планы и процедуры резервного копирования и восстановления данных (или дать лучший совет своему клиенту / коллеге / клиенту / другу / что угодно).

Answer 2

Мне нечего предложить, кроме как надеяться, что вы учитесь на моих ошибках. СТОП! Сделайте копию диска. dd может помочь вам в этом, и есть множество приложений для создания образов дисков, которые предоставят вам приятный пользовательский интерфейс. Я сделал ошибку: копался в fsck, искал резервные суперблоки и т.д. И т.д., Не дублируя диск. Я потерял абсолютно все. Похоже, вы уже решили работать без резервных копий, но еще не слишком поздно захватить копию диска, прежде чем вы его уничтожите с помощью попыток восстановления из лучших побуждений.

Я наткнулся на эту статью на восстановление в аналогичных обстоятельствах. Похоже, вы можете указать mount использовать другой суперблок. В сочетании с -t ext3 это может дать небольшую надежду.

Answer 3

Backtrack - это дистрибутив Linux, который поставляется с множеством инструментов для подобных вещей. Он также, однако, направлен прямо на верхний уровень опытных пользователей. На их веб-сайте могут быть хорошие учебники по использованию их инструментов, которые могут быть вам полезны.

Answer 4

Вы уверены, что /dev /sdd1 действительно тот диск, который вы ищете, а не какой-то другой диск? Наименование устройства зависит от порядка подключения дисков и может отличаться, например, при последующем подключении USB-накопителя по сравнению с подключением при загрузке. Используйте /dev/disk/by-id/ чтобы убедиться, что вы касаетесь нужного диска.

Следующим шагом будет выяснить, если весь диск или только раздел является тост, чтобы сделать этот запуск:

cfdisk /dev/sdd

Или другой инструмент по вашему выбору, чтобы увидеть, находятся ли разделы в нужном месте и как вы ожидали. Если таблица разделов является toast, вы можете попробовать gpart восстановить их или воссоздать их с нуля, если вы помните их расположение.

dmesg что-нибудь подозрительное? На умирающих жестких дисках вы в большинстве случаев будете получать множество сообщений об ошибках.

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

Answer 5

Если вы можете загружаться с livecd во время загрузки, не используйте swap, а затем вы можете смонтировать этот /dev/sda и скопировать все данные с него, если у вас есть жесткий диск USB или по сети. Затем вы можете перезагрузить систему и переформатировать данные.

Answer 6

Если вы используете LVM2 на своем диске, вам, вероятно, потребуется запустить его, прежде чем пытаться восстановить том. Попробуйте сначала, чтобы увидеть, если есть тома.

sudo pvscan && sudo vgscan && sudo lvscan

Любые тома, которые вы найдете, будут подключаться к устройству вместо прямой ссылки, такой как /dev/sdd1 .

Если вы не используете LVM на диске, вы всегда можете попытаться повторно смонтировать диск как Ext * 2 * вместо Ext * 3 *, поскольку он обратно совместим. Хотя это открывает окно для незначительного повреждения файловой системы (поскольку журнал не воспроизводится), оно позволяет вам получить доступ к остальной части ваших данных, поскольку вы уже указали, что бит "чистой" файловой системы уже установлен. Когда вы собираетесь перемонтировать том, вам нужно будет указать тип файловой системы напрямую, то есть:

sudo mount -t ext2 /dev/sdd1 /media/disk-7 && ls /media/disk-7

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

Следовать за:

Быстрый Google показывает результат, который подразумевает, что у вас может быть проблема с версиями ядра. Вы обновляли ядро или собирали собственный образ? Просто любопытно.