Спасаем данные в 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 Вам в помощь.
    Share post

    Comments 18

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

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

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

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

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

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

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

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

                        Вот он: https://techoverflow.net/blog/2015/01/07/fixing-bad-blocks-on-hdds-using-fixhdd.py/
                        Зеркало: https://github.com/unxed/fixhdd

                        Запускать так:
                        sudo fixhdd.py --loop /dev/sda
                        где /dev/sda — (потенциально) сбойный диск, с которого читаем.

                        При этом скрипт будет висеть в памяти и раз в 5 секунд сканировать системный лог на предмет сообщений об ошибках чтения, извлекать оттуда LBA-адреса сбойных секторов и писать в эти сектора нули, чтобы контроллер винта мог смело заремаппить сектор (при чтении-с-ошибками контроллер этого сделать не может, так как это — гарантированная потеря данных, которые, возможно, всё же есть какой-то маленький шанс считать).

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

                        Only users with full accounts can post comments. Log in, please.