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

после недавнего сбоя питания, из-за которого мой 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

так, может быть, указать тип fs?

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

Googling для signal 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] 

все еще надеясь, что этот сбой имеет какое-то отношение к отключению питания, я предполагаю, что суперблок поврежден или что-то в этом роде, и попробуйте другое: (сначала я определяю, что мой размер блока 32k с помощью 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

за Эйвери Пейн ниже я попробовал следующее:

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 или методы и т. д., Я был бы очень признателен!

6 ответов:

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы используете 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 выдает результат, который подразумевает, что у вас может быть проблема с версиями ядра. были ли вы обновление ядра, или вы скомпилировали собственное изображение? Просто любопытно.

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

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

cfdisk /dev/sdd

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

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

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

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