GNU ddrescue — лучшая утилита для восстановления данных с поврежденного жесткого диска
Оригинал: GNU ddrescue – The Best Damaged Drive Rescue
Автор: Carla Schroder
Дата публикации: 2 марта 2017 года
Перевод: А. Кривошей
Дата перевода: апрель 2018 г.
Когда вы спасаете свои данные с умирающего жесткого диска, время имеет большое значение. Чем дольше требуется копировать ваши данные, тем больше вы рискуете потерять. GNU ddrescue — это превосходный инструмент для копирования умирающих жестких дисков, а также любых блочных устройств, таких как компакт-диски, DVD-диски, USB-накопители, Compact Flash, SD-карты — все, что распознается вашей системой Linux как /dev /foo. Вы можете скопировать устройства, предназначенные для Windows и Mac OS X, поскольку GNU ddrescue работает на уровне блоков, а не на уровне файловой системы, поэтому не имеет значения, какая файловая система находится на устройстве.
Вместо того, чтобы запускать какие-либо средства восстановления файлов или инструменты анализа на поврежденном томе, лучше всего сначала сделать копию, а затем работать с этой копией.
Мне нравится всегда иметь под рукой SystemRescueCD на компакт-диске, а также на USB-накопителе. SystemRescueCD имеет небольшой объем и специализируется на спасательных операциях. В наши дни большинство дистрибутивов Linux имеют загрузочные версии с live-режимом, поэтому вы можете использовать то, с чем вам удобно работать, при условии, что вы ваш дистрибутив включает GNU ddrescue и другое программное обеспечение для спасения данных, которое вам нужно.
Не путайте GNU ddrescue с dd-rescue от Курта Гарлоффа . dd-rescue старше, и дизайн GNU ddrescue, вероятно, выиграл от этого. GNU ddrescue работает быстро и надежно: он пропускает плохие блоки и копирует хорошие блоки, а затем возвращается, чтобы попытаться скопировать поврежденные блоки, отслеживая их местоположение с помощью простого лог-файла.
Требуемое оборудование
Вам нужна система Linux с GNU ddrescue (gddrescue в случае Ubuntu), диск, который вы пытаетесь спасти, и устройство с пустым разделом, размером по крайней мере, в 1,5 раза больше, чем тот, который вы спасаете, так как у вас должен быть приличный запас свободного места. Если вы исчерпали свободное место, даже если это всего лишь несколько байтов, GNU ddrescue завершится неудачно в конце операции.
Есть несколько способов настройки оборудования. Один из способов — установить поврежденный диск в вашей Linux-системе, что очень просто, если это оптический диск или USB-устройство. Для дисков SATA и SDD имеются недорогие н простые в использовании адаптеры USB. Я предпочитаю подключать поврежденный диск к своей надежной системе Linux, а не зацикливаться на загрузчиках и странном железе. Для хранения спасенных данных я использую запасной диск SATA в переносном USB-кейсе.
Другой способ — загрузить компьютер, в котором находится умирающий диск, с помощью SystemRescueCD (или любого другого подобного дистрибутива), и подключить накопитель для копирования данных.
Если у вас недостаточно USB-портов, незамененимым является мощный USB-концентратор.
Идентификация накопителей
Убедитесь, что вы используете правильные имена устройств. Подключите все, а затем запустите lsblk:
Как видно из этого примера, вполне возможно ошибиться. У меня два диска по 1,8 TB. На одном корневая файловая система и мой домашний каталог, а другой — дополнительный накопитель для хранения данных. lsblk точно определяет флэш-накопитель, SD-карту и оптический привод. Если вы не сможете определить ваши диски, попробуйте findmnt:
Здесь видно, что корневой файловой системой является /dev/sda3, а все, что находится в папке /media, не относится к корневой файловой системе.
/media/carla/100MB2 и /media/carla/50MB обозначены метками вместо UUID типа /media/carla/8c670f2e-dae3-4594-9063-07e2b36e609e, так как я всегда присваиваю своим USB-накопителям понятные имена. Это можно делать для любой файловой системы, например я могу присвоить имя своей корневой файловой системе:
Запустите sudo e2label [device], чтобы увидеть вашу новую метку. e2label подходит для файловых систем ext2/ext3/ext4, а для XFS, JFS, BtrFS и других файловых систем имеются свои команды. Упростить этот процесс можно с помощью GParted: отключите файловую систему, а затем вы можете присвоить или изменить метку без использования команд для каждой файловой системы.
Основы восстановления данных
Мы потратили достаточно времени на выяснение того, как узнать, где какой диск. Предположим, что GNU ddrescue запущена на /dev/sda1, поврежденный диск — /dev/sdb1, и мы копируем его в /dev/sdc1. Первая из приведенных ниже команд копирует как максимально возможное количество данных без повторных попыток. Вторая команда снова работает с поврежденной файловой системой и делает три попытки чтения. Лог-файл находится в корневой файловой системе, которая, по моему мнению, лучше, чем съемный носитель, но вы можете поместить его куда считаете нужным:
Чтобы скопировать весь диск, используйте только имя диска, например /dev/sdb, и не указывайте раздел.
Если у вас есть поврежденные файлы, которые ddrescue не может полностью восстановить, вам понадобятся другие инструменты для их восстановления, такие как Testdisk, Photorec, Foremost или Scalpel. В Arch Linux wiki есть хороший обзор инструментов для восстановления файлов.
В следующих статьях вы найдете описание других средств для восстановления утерянных данных:
Источник
Ddrescue linux как пользоваться
Притащил мне юзер, значит, флешку. «Не открывается», говорит, «а там файлы очень нужные», такие дела. На самом деле флешка открывалась, но при попытке скопировать файлы компьютер вешался намертво. Скорее всего, выдернули не вовремя из разъёма — можно было бы просто ткнуть её себе в комп и попытаться натравить на раздел вендовый scandisk. Но файлы то «очень нужные», есть вероятность что флешка «немного умирает», так что пришлось действовать осторожно, чтобы не убить :). 
Образ снять можно по-разному. Под windows есть несколько простых и бесплатных программок, но они не заточены на то, чтобы снимать данные с диска, на котором читаются не все блоки. Если такая программа примется каждый не читаемый сектор читать по нескольку раз — диск может помереть окончательно, унеся с собой все ещё не прочитанные байты, даже те, которые можно было бы прочитать до запуска программы. Гугление по форумам подсказывает, что есть R-Studio, есть WinHEX — но они платные, кряки искать не охота, да и не алё как-то ломаный софт на работе использовать. Есть такая неплохая штука, как Non-Stop Copy, но это немного не то т.к. работает на уровне файлов. В итоге, бесплатной и «проверенной временем» софтины под Windows для этой цели — при поверхностном гуглении обнаружить не удалось, поэтому стал смотреть в сторону linux-ового софта.
Вариант с dd отметаем сразу — его недаром в народе прозвали Disk Destroyer — вполне может и добить полуживое устройство теми же самыми повторными попытками прочитать один и тот же сбойный блок. Но есть как минимум две известные софтины, умеющие именно то, что нужно — сначала прочитать то, что ещё можно прочитать, и только потом более вдумчиво ковырять проблемные места. Называются они, что характерно, практически одинаково — dd_rescue и ddrescue (GNU ddrescue). Обе программы более-менее активно развиваются до сих пор, но духи (хабр, гугл и прочий инет) говорят, что ddrescue умеет всё что нужно «из коробки», а вот dd_rescue приходится «прокачивать» скриптом на bash, если это не сделать — dd_rescue работать будет жутко медленно. У dd_rescue, как говорят, есть ощутимое преимущество в способности по-всякому сжимать поток и засылать его в pipe, но мне оно не надо. Значит, берём ddrescue. Установить в Debian её можно как-то так:
Теперь нужен компьютер с linux. Идеально, конечно, загрузить что-то вроде Debian на реальном и живом компьютере, но в принципе сойдёт и минимальная установка, живущая внутри VirtualBox — по крайней мере, мне этот вариант вполне удобен, хотя виртуализация порой добавляет немного проблем — о встретившихся виртуальных граблях расскажу по ходу повествования.
Для GNU ddrescue существует GUI на питоне (в репозиториях отсутствует, можно взять отсюда), но у меня он нормально не заработал (возможно, дело в версии python), так что пришлось читать документацию к консольной утилите :). Опций там много разных, и со всем этим разным вдумчивый читатель может ознакомиться самостоятельно, набрав в консоли info ddrescue (или pinfo ddrescue, что имхо гораздо удобнее). Те же, кто менее вдумчив, или кому нужно просто ехать, а не шашечки — сразу зайдут в раздел examples документации и обнаружат, что типовые параметры запуска достаточно просты.
Так запускается первый проход по диску. С диска /dev/hda пишется образ в filename.ddr, лог (он важен!) сохраняется в logfilename.log. Опция -n заставит программу бережнее относиться к плохим блокам — не пытаться повторять чтение или искать в плохом блоке читаемые куски меньшего размера. Теоретически можно в первый проход использовать ещё и опцию -d чтобы программа работала с диском напрямую, не обращаясь к кешу операционной системы, но для этого нужно либо задать правильный размер сектора опциями, либо понадеяться, что размер по умолчанию соответствует реальному для устройства :). В моём случае (с флешкой) размер в 512 байт по умолчанию подошёл, т.е. в первый проход данные нормально читались с опцией -d.
Сам процесс чтения и записи образа сопровождается выводом в консоль информации о скорости и прогрессе выполнения, так что GUI не сильно то и нужен.
Второй проход — с прямым доступом к диску и уже не осторожничаем, каждый сбойный блок пытаемся прочитать по три раза. Программа при этом пользуется данными, сохранёнными в первом проходе в лог-файл, при этом те данные, которые уже были успешно вынуты с проблемного диска — повторно не читаются, ddrescue просто пытается вытянуть с диска всё, что ещё возможно.
Всё, теперь можно или пытаться использовать продвинутые возможности ddrescue чтобы спасти ещё немного данных (если спасено не всё), либо скармливать полученный файл любой программе для препарирования образов диска и вынимать оттуда информацию. В принципе, можно просто переписать образ на исправный диск с помощью dd
Запишет содержимое образа на диск /dev/hdb блоками по 10 мегабайт (если оставить размер блока по умолчанию — снизится скорость копирования). Теперь можно натравливать на диск любые проверялки файловых систем и монтировать это дело стандартными средствами операционок.
Как вариант (если считалось всё или почти всё) — можно починить файловую систему прямо в образе (образ стоит забекапить перед этим), затем смонтировать сам образ и вынуть оттуда выжившие файлы. И тут нужно обратить внимание на следующее — если образ снимался с устройства целиком — значит, в файле образа лежит не только раздел с файловой системой, но и MBR (либо GPT для EFI) — т.е. таблица разделов и, возможно, код загрузчика. Поэтому просто так взять и натравить на полный образ диска какой-нибудь mount или dosfsck — нельзя. Либо сразу создавайте образы с отдельных разделов, либо придётся читать таблицу разделов и задавать до них смещения. Проще всего просмотреть таблицу разделов, натравив на файл образа linux-овый fdisk.
Опция u заставляет fdisk отображать смещения в секторах, а не в цилиндрах (чтобы не пересчитывать цилиндры в байты); опция c отключает устаревший режим MSDOS, который, в общем-то, не мешает, но документация рекомендует его отключать. В результате получим что-то типа такого:
# fdisk -uc ./ filename.ddr
You must set cylinders.
You can do this from the extra functions menu.
Command (m for help): p
Disk ./ filename.ddr : 0 MB, 0 bytes
32 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x06392f78
Device Boot Start End Blocks Id System
./rescue.ddr1 * 63 7553951 3776944+ b W95 FAT32
Command (m for help): q
Красным выделены команды, которые нужно дать с клавиатуры. Команда p заставит вывести информацию по разделам, команда q — завершить работу fdisk. Как видно, в одном секторе 512 байт, а первый и единственный раздел файловой системы внутри образа — начинается с 63 сектора, т.е. первый байт файловой системы смещён от начала файла образа на 63*512=32256 байт.
Однако fdisk не умеет работать с GPT (это новый формат таблицы разделов для EFI — более нового аналога BIOS) который, в частности, вместо MBR по умолчанию использует Windows 8. Поэтому альтернативный вариант — программа parted (не путать с gparted!). Скорее всего, она уже установлена, но если нет — что-нибудь вроде apt-get install parted спасёт отца русской демократии :). Натравливаем parted сразу на образ:
# parted ./filename.ddr
GNU Parted 2.3
Using ./filename.ddr
Welcome to GNU Parted! Type ‘help’ to view a list of commands.
(parted) unit s
(parted) print
Model: (file)
Disk ./filename.ddr: 7555528s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 63 s 7553951s 7553889s primary fat32 boot
Командой unit s включаем отображение размеров в секторах, иначе parted выдаст округлённо-приближённо-человекочитаемые цифры типа «32,3kB»», из которых получить точное число байт несколько проблематично. Командой print — получаем таблицу разделов. Командой q — выходим из parted. Собственно, здесь тоже видно, что размер сектора 512 байт, а смещение раздела — 63 сектора.
Теперь можно манипулировать разделом. Если нужно просто примонтировать его — достаточно примерно такой команды:
Монтирует файловую систему типа vfat (fdisk и parted выше недвусмысленно намекали, что файловая система раздела — fat32) из файла образа /root/temp/filename.ddr в каталог /mnt/tmp. Каталог, понятное дело, должен существовать. Опция loop заставляет mount самостоятельно подключить образ на loopback device (представить его в виде блочного устройства), а offset задаёт ранее добытое нами смещение в файле образа до начала раздела. Смещение в принципе можно записать в виде $((63*512)) — тогда bash самостоятельно вычислит 32256 и подставит в команду. Если образ снимался прямо с раздела — опцию offset нужно убрать.
Однако если образ не удалось снять с диска целиком и в нём остались «белые пятна» из не прочитавшихся блоков — файловая система может либо вообще не подмонтироваться, либо ошибки могут возникнуть в процессе работы с разделом. Теоретически подлатать раздел можно утилитой проверки вроде dosfsck, но для этого придётся руками подключить раздел из образа в виде блочного устройства:
Команда представляет раздел из образа /root/temp/filename.ddr со смещением (указано опцией -o ) в виде устройства /dev/loop0 . Если в образе несколько разделов и какие-либо разделы идут после того, с которым вы собираетесь работать — крайне рекомендуется установить ограничение размера опцией —sizelimit. В противном случае в устройстве /dev/loop0 будут видны не только байты нужного раздела, но и всех что идут за ним. Смещение конца раздела вычисляется точно так же как и для начала — смотрим что fdisk\parted выдаёт в End и умножаем количество секторов на размер сектора.
Теперь с устройством /dev/loop0 можно работать точно так же, как с каким-нибудь /dev/sda1 — монтировать, натравливать утилиты проверки файловых систем, утилиты для восстановления данных. в общем, что угодно. Например, попытаемся восстановить файловую систему:
Опция -a заставит исправлять ошибки автоматически. Подмонтировать можно примерно так:
Если блочное устройство больше не нужно и его надо отсоединить — используем опцию -d.
Несколько слов о работе через VirtualBox.
- Во-первых, если не устанавливать расширения (а их бесплатно нельзя использовать «в коммерческих целях» т.е. на работе) — скорость работы usb будет достаточно низкой. Для флешки это ещё терпимо, а вот съёмный usb-винт так прочитать в разумные сроки нереально. А уж если речь о IDE или SATA-винте — мне лично гораздо проще воспользоваться стареньким, нигде и никому уже не нужным системником, чем расковыривать свой рабочий компьютер, а потом пробрасывать диск в виртуальную машину :).
- Во-вторых — в VirtualBox есть удобная функция, позволяющая быстро пробросить локальную директорию внутрь виртуальной машины (монтируется командой вида mount -t vboxsd sharename mountpoint ), однако работает она странно и не идеально. Например, сохранить в такую директорию образ с помощью ddrescue — можно, а вот подмонтировать — уже нельзя (в блочном устройстве получаются какие-то совершенно левые последовательности байтов), приходится или копировать образ внутрь виртуальной машины, или давать доступ к файлу образа каким-либо иным способом, скажем по сети.
В общем, по-быстрому поковырять флешку удобнее может быть с виртуальной машины. Но с целью чего-то посерьезнее держать наготове системник, в том числе с установленным дистрибутивом linux — на мой взгляд, всё же оптимальный вариант. Кстати, вместо виртуалки можно установить на windows cygwin — там, помнится, была уже скомпиллированная под windows версия ddrescue.
Ну и о судьбе флешки, с которой всё началось — мне повезло и образ спокойно считался в режиме прямого доступа к диску в первом же проходе, без единой ошибки. Но сама флешка при этом умерла — не удаётся ни переформатировать файловую систему, ни восстановить scandisk-ом или dosfsck-ом, файлы же на флешке перестали видеться после первой же попытки починить файловую систему.
Файловая система внутри образа была немного повреждена. После восстановления с помощью dosfsck выяснилось, что несколько файлов побиты, но ничего важного среди них не было (только логи и конфиги portable-программы). Все хранившиеся там вордовские и прочие офисные документы уцелели и вернулись к своему владельцу.
Источник
