Диск Ext3 не смонтируется после сбоя питания; как восстановить файлы?
После последнего сбоя электропитания, который вызвал мое поле Linux (Ubuntu 8.10) к быстро выключению питания дважды от нормального состояния выполнения, у меня есть диск, который не смонтируется.
ОБНОВЛЕНИЕ: диск будет иногда монтироваться, но обнаруживаться как абсолютно пустой (даже Lost+Found) и показывать свободных 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.
Поиск с помощью Google для сигнала 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
На 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 утилиты восстановления данных или методы, и т.д., я был бы очень признателен за его!
6 ответов
Проблемы у Вас есть звук, намного более обширный, чем, что я ожидал бы от простой потери питания (даже во время довольно тяжелого действия записи) на устройстве. Я должен задаться вопросом, есть ли у Вас действительно больше проблем на уровне интерфейса/драйвера, или поврежденная таблица разделов или что-то вроде того вида.
От звуков вещей Вы, возможно, усилили проблему далее со всем метанием, Вы сделали при попытке устранить проблему.
Я не знаю, можем ли мы помочь с этим случаем, но еще не сдаемся.
Для будущего я предложил бы, чтобы Вы изучили следующую технику:
Когда Вы испытываете затруднения из-за диска в соответствии с Linux или UNIX, можно обычно использовать dd сделать копию растрового изображения целого устройства к некоторому другому местоположению. Найдите диск, это является, по крайней мере, столь же большим как одно рассматриваемое, и попробуйте команду как: dd if=$PROBLEMATIC of=$TARGET bs=4M ... будьте очень осторожны относительно если (входной файл) и (выходного файла) директивы. Отпуск, которые работают. Это - хорошая идея работать tail -f /var/log/messages & (или возможный вариант как соответствующий Вашему/etc/syslog.conf)... или делают это в фоновом режиме или в другом окне. Существуют расширенные версии dd который может обработать повторения и продолжающий прошлые сбойные блоки более надежно (sdd имя, которое приходит на ум). Но попытка просто с помощью запаса GNU dd команда сначала.
Можно сделать такую копию целого устройства (/dev/sdd, например) или просто раздел (/dev/sdd1). Если Вы получаете "короткое чтение или подобные ошибки затем, оно предполагает, что или устройство имеет физические ошибки при предотвращении чтений прошлые определенные цилиндры или, в случае раздела, что таблица разделов искажается в некотором роде. Можно даже сделать два различных dd изображения... один из каждого.
Вот прием: сделайте все Ваш fsck и mount попытки и использование Ваши различные другие средства восстановления, такие как TCT (Инструментарий Коронера) на скопированном изображении!
Это минимизирует потраченное выполнение времени диска (который возможно ухудшается на аппаратном уровне, поскольку Вы управляете им), и минимизирует влияние неудавшихся и возможно дезинформированные попытки восстановления. (В некоторых ситуациях Вы делаете одно изображение, затем другой на основе этого и всегда воздействуете на третичное изображение... зависит от того, насколько данные стоят).
Я лично предполагаю, что Вы выполняете что-то как hexdump или strings для прочтения изображения... просто позволяют ему прокручивать мимо в течение долгого времени и искать простой текст, который похож на него, могли бы быть фрагменты данных. Я использовал grep восстановить полезные (текстовые) данные из иначе полностью искаженных файловых систем. В случае, если я не предлагаю это в качестве героики восстановления данных..., но в качестве проверки работоспособности. Если Вы просматриваете 10-е путем прокрутки мегабайтов или нескольких гигабайтов данных и не видите распознаваемого текста... затем у Вас, вероятно, есть безнадежный случай, или Вы сделали что-то очень неправильно (Вы были действительно осторожны относительно тех если = и = опции?).
Я не знаю, поможет ли какое-либо из этого Вам с текущим усилием. Но изучите эти приемы теперь, и они определенно превратят Ваш следующий набег в намного менее страшное восстановление данных. (Да, практика в здоровой системе несколько раз---идет, используют Hex-редактор и пытаются добавить Ваше собственное творческое повреждение тут и там---к КОПИИ, конечно! Затем попробуйте, фиксируют его).
О, и это - действительно хорошее время, чтобы рассмотреть Ваше резервное копирование и планы восстановления данных и процедуры (или предоставить лучшую консультацию Вашему customer/colleague/client/friend/whatever).
-
1Используя ddrescue лучше в таких ситуациях, поскольку он зарегистрирует отказавшие секторы и продолжится вместо того, чтобы терпеть фиаско как dd. Последующим выполнениям можно сказать только попытаться читать из неудавшихся секторов, значительно ускорив их. – eleven81 09.09.2009, 19:33
У меня нет многого для предложения, кроме надеяться, что Вы учитесь на моих ошибках. ОСТАНОВИТЕСЬ! Сделайте дубликат диска. dd может помочь Вам сделать это, и существует много диска приложения обработки изображений, которые дадут Вам хороший пользовательский интерфейс. Я сделал ошибку копания в fsck, поиска резервных суперблоков, и т.д. и т.д. без первого дублирования диска. Я потерял абсолютно все. Похож Вы уже решили обойтись без помощи резервных копий, но не слишком поздно для ловли копии диска перед уничтожением его далее с полными благих намерений попытками восстановления.
Я действительно спотыкался через эту статью о восстановлении при подобном обстоятельстве. Похож на Вас, может сказать, монтируются для использования другого суперблока. Объединенный с-t ext3, это может предложить некоторую маленькую надежду.
Отслеживание в обратном порядке является дистрибутивом 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 поднимает результат, который подразумевает, что у Вас могла бы быть проблема управления версиями ядра. Вы обновляли свое ядро, или Вы компилировали пользовательское изображение? Просто любопытный.
-
1Спасибо! мысль у, нас есть победитель, я получи сообщение об ошибке, и не может смонтируйтесь как ext2. Я добавляю информацию к вопросу – privatehuff 01.09.2009, 04:01
Если можно загрузиться с livecd при начальной загрузке использования никакая подкачка, и затем можно смонтировать это /dev/sda и скопируйте все данные оттуда, если у Вас есть USB жесткий диск или по сети. Затем можно перезагрузить систему, переформатировали и выводят назад данные.
-
1Это не будучи мой загрузочный диск (я нахожусь на компьютере прямо сейчас), это другим диском данных, который я воображу, пишет в то, когда питание можно выйти. – privatehuff 01.09.2009, 03:53
Вы уверены, что/dev/sdd1 является действительно диском, который Вы ищете и не некоторый другой диск? Именование устройства зависится от порядка диски, где включено и могло бы отличаться, например, когда Вы включаете Карту памяти позже по сравнению с включением его на начальной загрузке. Использовать /dev/disk/by-id/ быть уверенным, что Вы касаетесь правильного диска.
Следующий шаг затем выяснил бы, является ли это целый диск, или просто раздел является тостом, чтобы сделать тот запуск:
cfdisk /dev/sdd
Или другой инструмент раздела по Вашему выбору, чтобы видеть, находятся ли разделы все еще в правильном месте и поскольку Вы ожидали, что они будут. Если таблица разделов является тостом, Вы могли бы попробовать gpart восстановить их или воссоздать их с нуля, если Вы помните их расположение.
dmesg вывод чего-либо подозрительного? На перестающих работать жестких дисках Вы большую часть времени получите множество сообщений об ошибках.
И поскольку другие упомянули, скопируйте данные прежде, чем попытаться изменить таблицу разделов или материал.