Диск Ext3 не будет монтироваться после сбоя питания; как восстановить файлы?
После недавнего сбоя питания, из-за которого мой linux box (Ubuntu 8.10) быстро выключился дважды из нормального рабочего состояния, у меня есть диск, который не будет монтироваться.
ОБНОВЛЕНИЕ: диск иногда монтируется, но отображается как полностью пустой (даже не потерянный + найденный) и показывает 14,9 ГБ свободного места (это диск на 500 ГБ). Когда я пытаюсь что-либо сделать, выдается ошибка разрешения, и диск отключается. (или, возможно, не был действительно установлен в первую очередь?)
Вот сообщение об ошибке, когда я пытаюсь смонтировать:
~ $ sudo mount -a
mount: неверный тип fs, неверный параметр, плохой суперблок в / dev / sdd1,
отсутствует кодовая страница или вспомогательная программа, или другая ошибка
В некоторых случаях полезная информация находится в системном журнале - попробуйте
Dmesg | хвост или около того Так, может быть, укажите тип фс?
~ $ sudo mount -t ext3 / dev / sdd1 / media / disk-7
mount: неверный тип fs, неверный параметр, плохой суперблок в / dev / sdd1,
отсутствует кодовая страница или вспомогательная программа, или другая ошибка
В некоторых случаях полезная информация находится в системном журнале - попробуйте
Dmesg | хвост или около того Нет же Так что-то напутало?
~ $ sudo fsck / dev / sdd1 fsck 1.41.3 (12 октября 2008 г.) e2fsck 1.41.3 (12 октября 2008 г.) /dev/sdd1: восстановление журнала fsck.ext3: при попытке открыть файл / dev / sdd1 такой файл или каталог отсутствуют Предупреждение... fsck.ext3 для устройства / dev / sdd1 завершено с сигналом 11.
Поиск сигнала 11 не был обнадеживающим, но я нашел несколько других способов восстановить диск:
~ $ sudo e2fsck / dev / sdd1
e2fsck 1.41.3 (12 октября 2008 г.)
/dev/sdd1: восстановление журнала
e2fsck: нет такого файла или каталога при попытке открыть / dev / sdd1
Суперблок не может быть прочитан или не описывает правильный ext2
файловая система. Если устройство действительно и действительно содержит ext2
файловая система (а не swap или ufs или что-то еще), то суперблок
поврежден, и вы можете попробовать запустить e2fsck с альтернативным суперблоком:
e2fsck -b 8193 [устройство] Все еще надеясь, что этот сбой как-то связан с отключением питания, я предполагаю, что суперблок поврежден или что-то в этом роде, и попробую другой: (сначала я определяю, что мой размер блока составляет 32 КБ, используя makefs -n)
~ $ sudo e2fsck -b 32768 / dev / sdd1 e2fsck 1.41.3 (12 октября 2008 г.) Флаг восстановления ext3 снят, но в журнале есть данные. Флаг восстановления не установлен в резервном суперблоке, так что журнал все равно работает. /dev/sdd1: восстановление журнала e2fsck: журнал должен быть не менее 1024 блоков при восстановлении ext3 журнал / dev / sdd1
За Avery Payne ниже я попробовал следующее:
sudo mount -t ext2 -o ro / dev / sdd1 / media / disk-7
Но получил это сообщение об ошибке:
mount: неверный тип fs, неверный параметр, плохой суперблок в / dev / sdd1,
отсутствует кодовая страница или вспомогательная программа, или другая ошибка
В некоторых случаях полезная информация находится в системном журнале - попробуйте
Dmesg | хвост или около того
~$ dmesg | хвост
[261157.639721] EXT2-fs: sdd1: не удалось подключить из-за неподдерживаемых дополнительных функций (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 dd команда сначала.
Вы можете сделать такую копию всего устройства (например, / dev / sdd) или только раздела (/dev/sdd1). Если вы получаете "короткое чтение или подобные ошибки, то это говорит о том, что либо у устройства есть физические ошибки, препятствующие чтению через определенные цилиндры, либо, в случае раздела, что таблица разделов искажена каким-либо образом. Вы можете даже сделать два разных dd изображения... один из каждого.
Вот хитрость: сделай все fsck а также mount попыток, и используйте ваши различные другие инструменты восстановления, такие как TCT (The Coroner's Toolkit) на скопированном изображении!
Это минимизирует время, затрачиваемое на работу накопителя (которое, возможно, ухудшается на аппаратном уровне при его эксплуатации), и сводит к минимуму влияние неудачных и, возможно, ошибочных попыток восстановления. (В некоторых ситуациях вы создаете одно изображение, затем другое, основываясь на этом, и всегда работаете с третичным изображением... зависит от того, сколько стоят данные) .
Я лично предлагаю вам запустить что-то вроде hexdump или же strings чтобы прочитать изображение... просто дайте ему долго прокручиваться и ищите простой текст, который выглядит так, как будто это фрагменты ваших данных. я использовал grep восстановить полезные (текстовые) данные из полностью искаженных файловых систем. В случае, если я не предлагаю это как героику восстановления данных... но как проверку здравомыслия. Если вы прокручиваете десятки мегабайт или несколько гигабайт данных и не видите какой-либо узнаваемый текст... тогда у вас, вероятно, безнадежный случай, или вы сделали что-то очень неправильное (действительно ли вы были осторожны с этим, если = и = варианты?).
Я не знаю, поможет ли что-нибудь из этого в текущем усилии. Но изучите эти приемы сейчас, и они определенно сделают ваш следующий шаг в восстановлении данных гораздо менее пугающим. (Да, попробуйте на здоровой системе один или два раза - иди используйте шестнадцатеричный редактор и попробуйте добавить свое творческое искажение тут и там - конечно же, в КОПИЮ! Затем попробуйте исправить это) .
О, и это действительно хорошее время, чтобы пересмотреть свои планы и процедуры резервного копирования и восстановления данных (или дать лучший совет своему клиенту / коллеге / клиенту / другу / что угодно) .
Мне нечего предложить, кроме как надеяться, что вы учитесь на моих ошибках. СТОП! Сделайте копию диска. dd может помочь вам в этом, и есть множество приложений для создания образов дисков, которые предоставят вам приятный пользовательский интерфейс. Я сделал ошибку: копался в fsck, искал резервные суперблоки и т. Д. И т. Д. Без предварительного дублирования диска. Я потерял абсолютно все. Похоже, вы уже решили работать без резервных копий, но еще не слишком поздно захватить копию диска, прежде чем вы его уничтожите с помощью попыток восстановления из лучших побуждений.
Я наткнулся на эту статью на восстановление в аналогичных обстоятельствах. Похоже, вы можете указать mount использовать другой суперблок. В сочетании с -t ext3 это может дать небольшую надежду.
Backtrack- это Linux-дистрибутив, который поставляется с множеством инструментов для подобных вещей. Он также, однако, направлен прямо на верхний уровень опытных пользователей. На их веб-сайте могут быть хорошие учебники по использованию их инструментов, которые могут быть вам полезны.
Если вы можете загрузиться с livecd во время загрузки, не используйте swap, а затем вы можете смонтировать это /dev/sda и скопируйте все данные оттуда, если у вас есть жесткий диск USB или по сети. Затем вы можете перезагрузить систему и переформатировать данные.
Вы уверены, что /dev/sdd1 действительно тот диск, который вы ищете, а не какой-то другой диск? Наименование устройства зависит от порядка подключения дисков и может отличаться, например, при последующем подключении USB-накопителя по сравнению с подключением при загрузке. использование /dev/disk/by-id/ чтобы быть уверенным, что вы касаетесь правильного диска.
Следующим шагом будет выяснить, если весь диск или только раздел является тост, чтобы сделать этот запуск:
cfdisk /dev/sdd
Или другой инструмент по вашему выбору, чтобы увидеть, находятся ли разделы в нужном месте и как вы ожидали. Если таблица разделов - тост, вы можете попробовать gpart восстановить их или воссоздать их с нуля, если вы помните их расположение.
Является dmesg выводить что-нибудь подозрительное? На умирающих жестких дисках вы в большинстве случаев будете получать множество сообщений об ошибках.
И, как уже упоминали другие, скопируйте данные, прежде чем пытаться изменить таблицу разделов или прочее.
Если вы используете 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 показывает результат, который подразумевает, что у вас может быть проблема с версиями ядра. Вы обновляли ядро или собирали собственный образ? Просто любопытно.