Linux для всех

индекс
247,21

Спасаем данные в Linux с помощью ddrecovery

«Input/output error (5)» сказала система при копировании файла и заставила погрузиться в неприятные раздумья о новом винчестере и подлом партизане SMART. К счастью все важные данные сохранились в резервных копиях, и всё-же постараться вытащить один файл очень хотелось — 34Гб образ виртуальной машины содержал в себе несколько документов потерять которые было бы неприятно.

Делать образ всего диска оказалось не лучшей идеей — место для этого отсутствовало, а ставить ещё один жёсткий очень не хотелось, вдобавок структура диска была цела и доступ к отдельным файлам оставался возможным. На помощь пришла утилита ddrescue, задача которой копировать файлы чтение которых затруднено — в первую очередь различных оптических дисков, но и жёстких дисков в нагрузку.

Первым делом потребовалось скачать утилиту — она идёт в стандартных пакетах Ubuntu(под именем gddrescue), но достаточно старой версии и некоторые полезные возможности не содержит.
По адресу ftp.gnu.org/gnu/ddrescue/ находится релиз 1.10, собирается простым набором «./configure && make && make install» и сразу готов к работе.

Немного теории — утилита ddrscue обладает одной очень полезной особенностью, она ведёт специальный лог, в котором отмечает проблемные\пропущенные места, и при дальнейших запусках уже использует этот файл пробует читать только то, что раньше распознать не удалось. Поэтому процесс восстановления будет идти в несколько этапов, сначала пытаемся максимально быстро распознать большую часть, а потом возвращаемя к проблемным участкам.

Первый проход запускается командой

ddrescue --no-split --verbose /media/disk-1/broken.vdi /media/disk-4/fixed.vdi /media/disk-4/rescue.log

т.е. отключаем повторные чтения и попытки минимизировать проблемные зоны, указываем откуда и куда копировать и файл лога. Понятно что копировать файл на тот-же диск идея плохая. Исходная файловая система ext3, раздел куда копируется ext2.

Лог восстановления — параметр не обязательный, но при многопроходном варианте нужен, и если в первый проход его создать забыли, то можно использовать --generate-logfile, полученный лог будет больше оптимального, но для дальнейших проходов полностью подойдёт.

В моём случае первый проход занял больше дня и сообщил о следующем
rescued: 22093 MB, errsize: 12264 MB, errors: 3876
картина не самая приятная, но уже что-то, начинаем второй проход.

ddrescue --direct --max-retries=2 --verbose /media/disk-1/broken.vdi /media/disk-4/fixed.vdi /media/disk-4/rescue.log

теперь пробуем прочесть диск в режиме прямого доступа и с 2 повторными попытками. Это число можно увеличивать, но в моём случае это только увеличивало время и результатов не приносило. (А вот при копировании CD вполне может дать результат).

Второй проход занял ещё около 15 часов, причём значительно улучшил картину:
rescued: 34292 MB, errsize: 65220 kB, errors: 16659
но попробуем вернуть остатки

ddrescue --retrim --max-retries=2 --verbose /media/disk-1/broken.vdi /media/disk-4/fixed.vdi /media/disk-4/rescue.log

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

Через два часа восстановление прерываю, результат
rescued: 34293 MB, errsize: 64579 kB
понятно что резкого улучшения ждать не стоит. С другой стороны для файлов небольшого размера (10-100мб) именно третий проход давал максимум данных, так что зависит от везения и характера проблем.

Образ был успешно добавлен в VirtualBox, проверен стандартным chkdsk и все необходимые данные скопированы, погибшие 60 мегабайт пришлись на системные файлы. Времени на всё ушло чуть более двух суток, что конечно много, но приемлемо.

Удачного восстановления, и не забывайте делать бекапы, они стоят потерянного времени, но а на крайний случай, ddrescue Вам в помощь.
+40
12 апреля 2009, 02:55
91
Riz

комментарии (15)

+7
LeKot #
спасибо. в избранное. на черный день =)
+1
Riz #
Пожалуйста, но только помните — данное решение будет не везде к месту. Иногда лучше сделать образ всего диска, ну а иногда лучше просто передать его в руки профессионалов.
+3
Deaddy #
Это тот опыт, приобретения которого обычно хочется избежать.
0
Riz #
Увы, даже у самого аккуратного человека может случится подобная неприятность, а так я Вас всецело поддерживаю.
+1
darkstyler #
да, лучше выработать у себя привичку постоянно делать бекапы важной информации
+1
Riz #
а лучше всего — настроить его по планировщику и забыть :)
0
d1v3r #
Эх… была бы эта статья на месяц раньше…
Посыпался переносной диск WD Passport на 160 гб.

Пытался сделать образ, восстановить dd'ой и ddrescue.
Была проблема, что восстановление замирало на одной точке, хотя max-retries ставил в 1.

В общем я сделал копию данных с помощью бесплатной виндовой программы Unstoppable Copier, а неделю назад сдал диск на ремонт по гарантии.

Часть данных так и не удалось восстановить…
+1
Riz #
Замереть оно могло по той причине? что попало на большую битую область, чтобы этого избежать как раз и пришлось шаманить с многопроходным вариантом. За unstoppable copier спасибо, надо запомнить. Хотя боюсь c ext разделов он бессилен что-то восстановить :)
0
d1v3r #
Вот прочитав твою статью раньше — вероятно восстановил бы больше данных :)

Всё делал по манам, но видимо чего-то не хватило…
Ну в общем не сильно переживаю — там не было жизненно важных данных.

За рекомендацию не стоит благодарить. Сам был рад её найти, т.к. другие программы не справлялись. Хоть она довольно плоха интерфейсом, да и безошибочностью не блещет — но те данные которые смогла — достала.
Мой диск был отформатирован FAT32, так что программа UC нормально справилась.
Думаю, что если подмонтировать ext с помощью специальных драйверов под Windows — можно и с него достать. Так делать не пробовал, но по-идее должно сработать.

За статью ещё раз спасибо — вдруг в будущем пригодиться?
0
GloooM #
В мартовском LinuxFormat тоже была статейка на эту тему.
0
Riz #
Увы, не читаю. :(
0
davnozdu #
Лучше снять полный образ раздела/диска
Подключаем образ через loop устройство и уже с ним производим всякие манипуляции.
Это даст нам право на ошибку если что-то пойдёт не так.

0
Riz #
Вот был уверен что кто-то то напишет так. Правильно — то оно правильно, но лишнего диска на пол терабайта под рукой не было. Плюс, судя по скорости с которой удалось прочитать ~34гБ, я бы на месяц засел бы.
+1
unxed #
Есть сборка под windows (cygwin) (бинарник 1.9,
статья про восстановление данных с hdd, используя его и другой кроссплатформенный free/open source софт).
0
Riz #
Спасибо, очень полезно.

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