Powered by Invision Power Board


  Ответ в темуСоздание новой темыСоздание опроса

> Восстановление данных под Linux
Mentat
Дата Oct 2 2007, 08:54 AM
Цитировать сообщение








Группа: Members
Сообщений: -2
Пользователь №: 1
Регистрация: 14-November 06





Цитата

Восстановление данных под Linux

    Несколько вступительных слов.

    Несмотря на упорное сопротивление некоторых производителей "очень маленького программного обеспечения" вкупе с анонимусами с linux.org.ru , linux не спеша, но уверенно занимает места на десктопах пользователей. Как только не отговаривали среднестатистического юзера от знакомства с желтопятым Туксом: и что, мол, Линукс - это ОС для "красноглазых программистов" (и таки правда - Линукс замечательная свободная платформа для разработчика ПО с уймой этих самых средств разработки), что Линукс - это сугубо серверная ОС (и таки да - Линукс отлично зарекомендовал себя и на тяжелых веб-серверах и на примитивных роутерах) и т. д., и т. п. И помимо этого, благодаря усилиям тысяч энтузиастов при поддержке хардверных и софтверных гигантов (один ibm чего стоит), пингвин уверенно взгромоздился на десктоп и в качестве офисного рабочего места, и в качестве игровой машины, и в качестве мультимедийного центра "из коробки". Эта тенденция не может не радовать. Но что может дать Линукс, к примеру, в столь специфической сфере, как восстановление данных с неисправных hdd? Автор, исходя из специфики своей трудовой деятельности, решил задаться этим вопросом.

    Решив не размениваться на мелочи, автор сразу поставил достаточно сложную и нетривиальную для Линукса задачу: снятие данных исключительно свободными средствами Линукс с сильно забэдовавшегося винчестера samsung объемом 200 ГБ, на котором, к тому же, было установлено юзер-френдли поделие microsoft windows xp. Требование заказчика - скопировать "всего 2 папки с диска d". Текущие симптомы со слов заказчика: windows не грузится, винчестер долго "чухается"... и ничего не происходит - черный экран. При попытке подключить его к другой исправной машине, установленный на ней windows грузится минут 20, нещадно шкарябая полудохлым винчестром в попытке что-то там найти и автоматически смонтировать. В результате загрузка таки происходит, в Проводнике виден только один раздел неизвестного размера, который "умный" Виндовз тут же предлагает "дружественно" форматнуть; в partitionmagic после тугого зависона виден 1 раздел, покрашенный желтым цветом  "с какой-то там ошибкой" и непотребным размером в 400 гигабайт.

    Сейчас последует стандартный отказ от каких-либо гарантий. Автор не отвечает за то, что с правами суперпользователя вы легко можете стереть и свои и чужие данные без какой-либо возможности восстановления. Автор снимает с себя ответственность за то, что вы, не имея опыта, неверно оценили состояние своего или чужого накопителя и добили ему полуживые головы, устроили запилы на поверхностях дисков, дожгли глюкавую плату контроллера винчестера. Автор не несет ответственности за то, что по этим причинам его собратья по восстановлению данных выставили вам круглые счета за работу. Как всякий нормальный человек вы конечно же подумали, взвесили все риски и лишь потом приступили к чтению и применению описанного ниже алгоритма. Удачи!

    Ну а теперь за работу, товарищи!
    В распоряжении автора ibm-pc совместимый компьютер на процессоре amd sempron 2800+, установленном в материнскую плату gigabyte ga-k8ne на логике nforce4-4x. На компьютере установлен совершенно недружественный к пользователю, вручную локализованный, slackware-10.2 (ядро 2.4.32) в полной инсталляции. Из дополнительных программ установлены: ddrescue, dd_rescue, testdisk и, на всякий случай, пакет ntfsprogs и ntfs-3g. Для начала договоримся, что ни в какие иксы мы грузиться не будем и попробуем обойтись даже без mc  (это по желанию).

    Небольшое примечание. У кого нет установленного на hdd Линукса, либо нет желания его устанавливать, может воспользоваться slackware-based (sic!) livecd riplinux-2.9 (ядро 2.6.21). В нем уже предустановлены основные нужные нам программы, как то: ddrescue, dd_rescue, testdisk. Единственный минус - не собрана поддержка koi8-r, поэтому кириллический раздел монтировать придется -o nls=utf8 и копировать данные придется уже из-под иксового файл-менеджера, т. к. поддержки utf8 в консоли нет, что, впрочем, не проблема, хоть и идеологически неправильно.

    Применим профессиональный подход к проблеме. А профессиональный подход подразумевает, что перво-наперво необходимо скопировать проблемный винчестер на исправный и дальнейшие работы вести уже с исправным, дабы глюки и подвисания инвалида не мешали нам. Достанем с полки (приобретем в магазине, одолжим у друзей) накопитель, равный по объему, либо больший, чем проблемный. У нас под рукой случайно оказался 500-гигабайтный wd с sata интерфейсом. Подготовим его к работе. Несмотря на то, что диск-приёмник вроде бы чист, перед началом процесса копирования хорошим тоном считается всё ж гарантированно его очистить с помощью того же dd. Для максимально быстрого стирания выставляем blocksize не менее 16 секторов накопителя, т. е 16*512b=8kb. Можно и больше.

    root@rozik3:~# dd if=/dev/zero of=/dev/sda bs=8k

    Процесс стирания 500-гигабайтного винта займет около 2-х часов. Пока что можно выйти покурить сигарет, поиграть с компьютером в шахматы, сходить на linux.org.ru пофлеймить.

    Периодически вводя от рута на втором терминале killall -sigusr1 dd наблюдаем на первом ход стирания.

    8034929+0 записей считано
    8034929+0 записей написано
    скопировано 65822138368 байт (66 gb), 832,959 секунд, 79,0 mb/s
    52809917+0 записей считано
    52809917+0 записей написано
    скопировано 432618840064 байт (433 gb), 6286,23 секунд, 68,8 mb/s
    #К концу диска, как и полагается, линейная скорость записи несколько уменьшается
    dd: запись `/dev/sda': no space left on device
    61048324+0 записей считано
    61048323+0 записей написано
    скопировано 500107862016 байт (500 gb), 7750,36 секунд, 64,5 mb/s

    Вот и чудненько. Выключаем компьютер, дабы только теперь подключить инвалида. Включились. БИОС тут же ругнулся на smart проблемного samsung'а: что, мол, немедленно сбэкапьтесь, после чего выкиньте его в окошко. Сейчас, сейчас. Именно сбэкапиться и хотим. Раз даже глупая материнка ругается на СМАРТ, то посмотрим и мы его для оценки ситуации.

    root@rozik3:~# smartctl -i -a /dev/hdc
    smartctl version 5.36 [i486-slackware-linux-gnu] copyright © 2002-6 bruce allen
    home page is http://smartmontools.sourceforge.net/

    === start of information section ===
    device model:    samsung sp2014n
    serial number:    s088j1nl203227
    firmware version: vc100-33
    user capacity:    200.049.647.616 bytes
    device is:        in smartctl database [for details use: -p show]
    ata version is:  7
    ata standard is:  ata/atapi-7 t13 1532d revision 4a
    local time is:    tue sep 18 00:12:19 2007 eest
    smart support is: available - device has smart capability.
    smart support is: enabled

    === start of read smart data section ===
    smart attributes data structure revision number: 16
    vendor specific smart attributes with thresholds:
    id# attribute_name          flag    value worst thresh type      updated  when_failed raw_value
      1 raw_read_error_rate    0x000f  253  099  051    pre-fail  always      -      0
      3 spin_up_time            0x0007  038  033  025    pre-fail  always      -      12800
      4 start_stop_count        0x0032  100  100  000    old_age  always      -      272
      5 reallocated_sector_ct  0x0033  001  001  010    pre-fail  always  failing_now 32267
      7 seek_error_rate        0x000f  253  253  051    pre-fail  always      -      0
      8 seek_time_performance  0x0025  253  253  015    pre-fail  offline      -      0
      9 power_on_half_minutes  0x0032  097  097  000    old_age  always      -      17476h+42m
    10 spin_retry_count        0x0033  253  253  051    pre-fail  always      -      0
    11 calibration_retry_count 0x0012  253  002  000    old_age  always      -      0
    12 power_cycle_count      0x0032  100  100  000    old_age  always      -      13
    190 unknown_attribute      0x0022  166  127  000    old_age  always      -      24
    194 temperature_celsius    0x0022  166  127  000    old_age  always      -      24
    195 hardware_ecc_recovered  0x001a  100  100  000    old_age  always      -      1228
    196 reallocated_event_count 0x0032  001  001  000    old_age  always      -      32267
    197 current_pending_sector  0x0012  253  001  000    old_age  always      -      4294935023
    198 offline_uncorrectable  0x0030  253  001  000    old_age  offline      -      4294935631
    199 udma_crc_error_count    0x003e  200  200  000    old_age  always      -      0
    200 multi_zone_error_rate  0x000a  253  253  000    old_age  always      -      0
    201 soft_read_error_rate    0x000a  253  089  000    old_age  always      -      0

    Имеем скачущие параметры с id 1, 197, 198, 201, говорящие о нестабильном чтении и имеющихся дефектах и рухнувший параметр с id 5, явно говорящий нам, что винчестер щедро просыпал бэдами и полностью забил ремапами g-list.

    С помощью fdisk сориентируемся в пространстве, чтоб случайно не потереть что-нибудь не то :) .

    root@rozik3:~# fdisk -l

    #Это наш чистый накопитель-приемник. На нем ничего нет.
    disk /dev/sda: 500.1 gb, 500107862016 bytes
    255 heads, 63 sectors/track, 60801 cylinders
    units = cylinders of 16065 * 512 = 8225280 bytes

    disk /dev/sda doesn't contain a valid partition table

    #Это наш инвалид.
    #Вместо внятной логической структуры - какое-то месиво - источник желтого цвета в partitionmagic и 400 ГБ размера.
    disk /dev/hdc: 200.0 gb, 200049647616 bytes
    255 heads, 63 sectors/track, 24321 cylinders
    units = cylinders of 16065 * 512 = 8225280 bytes

    this doesn't look like a partition table
    probably you selected the wrong device.

      device boot      start        end      blocks  id  system
    /dev/hdc1  ?      13578      119522  850995205  72  unknown
    partition 1 does not end on cylinder boundary.
    /dev/hdc2  ?      45382      79243  271987362  74  unknown
    partition 2 does not end on cylinder boundary.
    /dev/hdc3  ?      10499      10499          0  65  novell netware 386
    partition 3 does not end on cylinder boundary.
    /dev/hdc4          167628      167631      25817+  0  empty
    partition 4 does not end on cylinder boundary.

    partition table entries are not in disk order

    #Это, собственно, наш системный винчестер
    disk /dev/hda: 120.0 gb, 120059362816 bytes                       

    disk /dev/hda: 120.0 gb, 120059362816 bytes
    255 heads, 63 sectors/track, 14596 cylinders
    units = cylinders of 16065 * 512 = 8225280 bytes

      device boot      start        end      blocks  id  system
    /dev/hda1              1          65      522081  82  linux swap
    /dev/hda2              66        1340    10241437+  83  linux
    /dev/hda3  *        1341      14468  105450660    7  hpfs/ntfs
    /dev/hda4          14469      14596    1028160    c  w95 fat32 (lba)

    Исходя из выданных fdisk'ом имён файлов устройств будем продолжать дальнейшую работу.

    Чем же копировать? Вот вопрос. Линукс-гуру настойчиво предлагают не изобретать велосипед и использовать всё тот же dd
    root@rozik3:~# dd if=/dev/hdc of=/dev/sda bs=8k conv=noerror,sync
    где bs=8k опять же для пущей скорости, noerror не дает вылетать на ошибках, sync дописывает проблемные блоки нулями, чтоб не возникло смещений на приемнике.

    На сайте testdisk'а рекомендуют использовать ddrescue  в два прохода:
    root@rozik3:~# ddrescue -n /dev/hdc /dev/sda samsung200.log
    где n - не разбивать на исходном диске проблемные блоки для вычитки, в лог же ведется запись сессии для исключения успешно скопированных секторов из второго прохода:
    root@rozik3:~# ddrescue -r 1 /dev/hdc /dev/sda samsung200.log
    где -r 1 - однократная попытка чтения дефектного сектора при вычитывании с использованием сохраненного лога.

    Хорошие программы, правильные методы. Только, как выяснилось впоследствии, на инвалидном samsung'е приблизительно на 11-ом ГБ имеет место значительная дефектная зона, где при прямом копировании и вычитке головы начинают терять сервометки с логично вытекающим отсюда стуком. И если оставить винчестер копироваться на ночь, то на утро есть все шансы получить только первые 11 ГБ копии и монотонно стучащий трупик с дохлыми головами. Это нас совершенно не устраивает. Поэтому мы обратимся к не так сильно разрекламированной dd_rescue. Фичности у нее поменее будет, чем у ddrescue - она не умеет обрабатывать лог сессии и каждый запуск будет начинать, как буд-то ничего не происходило. Но реверсное копирование с лихвой перекрывает её недостаточную интеллектуальность и автоматичность. Итак, решено! В данном случае наш выбор - dd_rescue.

    Как водится, перед самым стартом на Луну :) покурим хелп на предмет управления звездолетом :) .

    root@rozik3:~# dd_rescue -h

    dd_rescue version 1.14, garloff@suse.de, gnu gpl
    ($id: dd_rescue.c,v 1.59 2007/08/26 13:42:44 garloff exp $)
    dd_rescue copies data from one file (or block device) to another.
    usage: dd_rescue [options] infile outfile
    options: -s ipos    start position in  input file (default=0),
              #начальный сектор на исходном файле-устройстве (по ум.=0)
            -s opos    start position in output file (def=ipos),
              #начальный сектор на результирующем файле-устройстве (по ум.=как на исходном)
            -b softbs  block size for copy operation (def=65536),
              #размер блока при нормальном копировании (по ум.=64 КБ)
            -b hardbs  fallback block size in case of errs (def=512),
              #размер блока при копировании на дефектах (по ум.=512 Б)
            -e maxerr  exit after maxerr errors (def=0=infinite),
              #завершить работу при определенном количестве ошибок (по ум.=0=не завершать)
            -m maxxfer maximum amount of data to be transfered (def=0=inf),
              #максимальный скопированный объем данных, по достижении которого завершить работу (по ум.=0=не завершать)
            -y syncfrq frequency of fsync calls on outfile (def=512*softbs),
              #частота вызова fsync для синхронизации результирующего файла с исходным (маленькое значение замедляет работу) (по ум.=каждые 32 МБ)
            -l logfile name of a file to log errors and summary to (def=""),
              #файл, в который захватывается вывод программы в терминал (полезно для анализа) (по ум.=не создается)
            -o bbfile  name of a file to log bad blocks numbers (def=""),
              #файл, в который пишутся номера дефектных секторов (полезно для анализа) (по ум.=не создается)
            -r reverse direction copy (def=forward),
              #реверсное копирование (!!!) (по ум.=выключено, копируем вперед)
            -t truncate output file (def=no),
              #очищать результирующий файл (как это делает dd) (по ум.=не очищать)
            -d/d use o_direct for input/output (def=no),
            -w abort on write errors (def=no),
              #завершать работу при ошибках записи (по ум.=не завершать)
            -a sparse file writing (def=no),
            -a always write blocks, zeroed if err (def=no),
              #записывать на приемник нули вместо ошибок (полезно, если не очистили приемник; несколько замедляет копирование на дефектах) (по ум.=не записывать)
            -i interactive: ask before overwriting data (def=no),
              #интерактивный режим: спрашивать при перезаписи данных (по ум.=отключен)
            -f force: skip some sanity checks (def=no),
            -p preserve: preserve ownership / perms (def=no),
            -q quiet operation,
              #копировать молча
            -v verbose operation,
              #копировать с максимумом подробностей
            -v display version and exit,
              #показать версию программы и выйти
            -h display this help and exit.
              #показать эту справку и выйти
    note: sizes may be given in units b(=512), k(=1024), m(=1024^2) or g(1024^3) bytes
    this program is useful to rescue data in case of i/o errors, because
    it does not necessarily abort or truncate the output.

    Осмыслив написанное, взлетаем :) .

    root@rozik3:~# dd_rescue -v -y 1g -l samsung200.log -o samsung200.bb /dev/hdc /dev/sda
    # -v - пусть пишет, что делает; -y 1g - синхронизация раз в гигабайт, иначе тормозит прилично; -l, -o - пусть ведет логи... для истории :)
    dd_rescue: (info): about to transfer 0.0 kbytes from /dev/hdc to /dev/sda
    dd_rescue: (info): blocksizes: soft 65536, hard 512
    dd_rescue: (info): starting positions: in 0.0k, out 0.0k
    dd_rescue: (info): logfile: samsung200.log, maxerr: 0
    dd_rescue: (info): reverse: no , trunc: no , interactive: no
    dd_rescue: (info): abort on write errs: no , sparse write: never
    dd_rescue: (info): ipos:  2283520.0k, opos:  2283520.0k, xferd:  2283520.0k
                      errs:      0, errxfer:        0.0k, succxfer:  2283520.0k
                +curr.rate:    54010kb/s, avg.rate:    50720kb/s, avg.load: 16.9%
    ------skip-------
    dd_rescue: (info): ipos:  10801400.5k, opos:  10801400.5k, xferd:  10801400.5k
                    *  errs:    449, errxfer:      224.5k, succxfer:  10801176.0k
                +curr.rate:        0kb/s, avg.rate:    10586kb/s, avg.load:  3.6%
    dd_rescue: (warning): /dev/hdc (10801400.5k): input/output error!

    dd_rescue: (info): ipos:  10801401.0k, opos:  10801401.0k, xferd:  10801401.0k
                    *  errs:    450, errxfer:      225.0k, succxfer:  10801176.0k
                +curr.rate:        0kb/s, avg.rate:    10544kb/s, avg.load:  3.6%
    dd_rescue: (warning): /dev/hdc (10801401.0k): input/output error!

    dd_rescue: (info): ipos:  10801401.5k, opos:  10801401.5k, xferd:  10801401.5k
                    *  errs:    451, errxfer:      225.5k, succxfer:  10801176.0k
                +curr.rate:        0kb/s, avg.rate:    10502kb/s, avg.load:  3.6%
    dd_rescue: (warning): /dev/hdc (10801401.5k): input/output error!

    bad block: 21602803
    dd_rescue: (fatal): caught signal 2 "interrupt". exiting!
    summary for /dev/hdc -> /dev/sda:
    dd_rescue: (info): ipos:  10801402.0k, opos:  10801402.0k, xferd:  10801402.0k
                      errs:    452, errxfer:      226.0k, succxfer:  10801176.0k
                +curr.rate:        0kb/s, avg.rate:    10461kb/s, avg.load:  3.6%

    Вот оно! На 11 гигабайте винт бешено захрюкал и затикал значительно громче, чем на предыдущих дефектах. По ctrl+c выходим. Теперь будем копировать задом наперед.

    root@rozik3:~# dd_rescue -r -v -y 1g -l samsung200.log -o samsung200.bb /dev/hdc /dev/sda
    # -r - реверс; логи дописываются
    dd_rescue: (info): ipos set to the end: 195360984.0k
    dd_rescue: (info): about to transfer 0.0 kbytes from /dev/hdc to /dev/sda
    dd_rescue: (info): blocksizes: soft 65536, hard 512
    dd_rescue: (info): starting positions: in 195360984.0k, out 195360984.0k
    dd_rescue: (info): logfile: samsung200.log, maxerr: 0
    dd_rescue: (info): reverse: yes, trunc: no , interactive: no
    dd_rescue: (info): abort on write errs: no , sparse write: never
    dd_rescue: (info): ipos: 195225816.0k, opos: 195225816.0k, xferd:    135168.0k
                -    errs:      0, errxfer:        0.0k, succxfer:    135168.0k
                +curr.rate:    14083kb/s, avg.rate:    14083kb/s, avg.load:  4.3%

    И идем спать :) . Начало мы уже получили. Теперь будет вычитываться с конца. Если даже и стукнет на проблемной зоне, то львиную долю копии мы получим. Копирование в реверс идет приблизительно втрое медленней прямого. Так и должно быть :) .

    ------------------------
    Ситуация на утро: dd_rescue прочесал проблемную зону и с 11-ю тысячами ошибок успешно завершил работу:

    dd_rescue: (info): ipos 7539736.0k promote to large bs again!
    dd_rescue: (info): ipos:      216.0k, opos:      216.0k, xferd: 195360768.0k
                -    errs:  11016, errxfer:      5508.0k, succxfer: 195355260.0k
                +curr.rate:    18205kb/s, avg.rate:    6161kb/s, avg.load:  2.3%
    summary for /dev/hdc -> /dev/sda:
    dd_rescue: (info): ipos:        0.0k, opos:        0.0k, xferd: 195360984.0k
                -    errs:  11016, errxfer:      5508.0k, succxfer: 195355476.0k
                +curr.rate:    17705kb/s, avg.rate:    6161kb/s, avg.load:  2.3%

    Ура! Выключаем компьютер, отсоединяем инвалида.

    Кстати, вполне трезвой мыслью является сделать бэкап посекторной копии уже с живого накопителя. Если есть в запасе еще один винт, то очень нелишне будет это сделать тем же dd.

    Включаемся опять. Еще раз запустим fdisk. Может быть в процессе переезда что-то изменилось к лучшему :) ?

    root@rozik3:~# fdisk -l

    disk /dev/sda: 500.1 gb, 500107862016 bytes
    255 heads, 63 sectors/track, 60801 cylinders
    units = cylinders of 16065 * 512 = 8225280 bytes

    this doesn't look like a partition table
    probably you selected the wrong device.

      device boot      start        end      blocks  id  system
    /dev/sda1  ?      13578      119522  850995205  72  unknown
    partition 1 does not end on cylinder boundary.
    /dev/sda2  ?      45382      79243  271987362  74  unknown
    partition 2 does not end on cylinder boundary.
    /dev/sda3  ?      10499      10499          0  65  novell netware 386
    partition 3 does not end on cylinder boundary.
    /dev/sda4          167628      167631      25817+  0  empty
    partition 4 does not end on cylinder boundary.

    partition table entries are not in disk order

    disk /dev/hda: 120.0 gb, 120059362816 bytes
    255 heads, 63 sectors/track, 14596 cylinders
    units = cylinders of 16065 * 512 = 8225280 bytes

      device boot      start        end      blocks  id  system
    /dev/hda1              1          65      522081  82  linux swap
    /dev/hda2              66        1340    10241437+  83  linux
    /dev/hda3  *        1341      14468  105450660    7  hpfs/ntfs
    /dev/hda4          14469      14596    1028160    c  w95 fat32 (lba) 

    Всё по-старому. Несмотря на то, что в mbr ничего, похожего на правду не обнаруживается, на всякий случай бекапим её.

    root@rozik3:~# dd if=/dev/sda of=samsung200.mbr.old count=1
    1+0 записей считано
    1+0 записей написано
    скопировано 512 байт (512 B), 0,000281 секунд, 1,8 mb/s

    Запускаем testdisk. Хоть он и консольный, но обладает интуитивно понятным интерфейсом с кнопками и менюшками :) .

    root@rozik3:~# testdisk
    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org
    please wait...

    После чего вылезает менюшка с выбором устройств:

    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org

      testdisk is free software, and
    comes with absolutely no warranty.

    select a media (use arrow keys, then press enter):
    disk /dev/hda - 120 gb / 111 gib
    disk /dev/sda - 500 gb / 465 gib

    [proceed ]  [  quit  ]

    note: disk capacity must be correctly detected for a successful recovery.
    if a disk listed above has incorrect size, check hd jumper settings, bios
    detection, and install the latest os patches and disk drivers.

    Выбираем стрелками на клавиатуре нужный девайс /dev/sda и жмем proceed

    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org

    disk /dev/sda - 500 gb / 465 gib

    please select the partition table type, press enter when done.
    [intel  ]  intel/pc partition
    [mac    ]  apple partition map
    [none  ]  non partioned media
    [sun    ]  sun solaris partition
    [xbox  ]  xbox partition
    [return ]  return to disk selection

    note: do not select 'none' for media with only a single partition. it's very
    rare for a drive to be 'non-partitioned'.

    Несмотря на то, что у нас amd :) , выбираем intel

    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org

    disk /dev/sda - 500 gb / 465 gib - chs 60801 255 63

    [ analyse  ]  analyse current partition structure and search for lost partitions
    [ advanced ]  filesystem utils
    [ geometry ]  change disk geometry
    [ options  ]  modify options
    [ mbr code ]  write testdisk mbr code to first sector
    [ delete  ]  delete all data in the partition table
    [ quit    ]  return to disk selection

    note: correct disk geometry is required for a successful recovery. 'analyse'
    process may give some warnings if it thinks the logical geometry is mismatched.

    Жмем analyse

    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org

    disk /dev/sda - 500 gb / 465 gib - chs 60801 255 63
    current partition structure:
        partition                  start        end    size in sectors
    1 * sys=72              13577 238 11 119521 238 60 1701990410

    bad relative sector.
    2 * sys=74              45381  70  3 79242  34 29  543974724

    bad relative sector.
    3 * netware 3.11+        10498  56 41 10498  56 40          0

    bad relative sector.
    only one partition must be bootable
    space conflict between the following two partitions
    1 * sys=72              13577 238 11 119521 238 60 1701990410
    2 * sys=74              45381  70  3 79242  34 29  543974724

    *=primary bootable  p=primary  l=logical  e=extended  d=deleted

    [proceed ]  [  save  ]
                                try to locate partition

    По результатам анализов наблюдаем то же безобразие, что и выдал нам fdisk. Жмем proceed, дабы попытаться обнаружить живые разделы.

    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org

    disk /dev/sda - 500 gb / 465 gib - chs 60801 255 63
        partition              start        end    size in sectors
    * hpfs - ntfs              0  1  1  5182 254 63  83264832 [win_xp]
    l hpfs - ntfs          5183  1  1 24320 254 63  307451907 [archive]

    structure: ok.  use up/down arrow keys to select partition.
    use left/right arrow keys to change partition characteristics:
    *=primary bootable  p=primary  l=logical  e=extended  d=deleted
    keys a: add partition, l: load backup, t: change type, p: list files,
        enter: to continue
    ntfs, 42 gb / 39 gib

    Жмем enter

    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org

    disk /dev/sda - 500 gb / 465 gib - chs 60801 255 63

        partition                  start        end    size in sectors
    1 * hpfs - ntfs              0  1  1  5182 254 63  83264832 [win_xp]
    2 e extended lba          5183  0  1 24320 254 63  307451970
    5 l hpfs - ntfs          5183  1  1 24320 254 63  307451907 [archive]

    [  quit  ]  [search! ]  [ write  ]  [extd part]
                                  return to main menu

    По оставшимся в живых бутсекторам testdisk обнаружил разделы. На этом можно было бы, нажав write, и завершить, тем более, что со слов заказчика размеры найденных разделов совпадают с предполагаемыми размерами утерянных. Но в целях повышения эрудиции пройдем всю цепочку до конца. Выбираем всё ж таки search!

    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org

    disk /dev/sda - 500 gb / 465 gib - chs 60801 255 63
        partition              start        end    size in sectors
    d hpfs - ntfs              0  1  1  2233 254 63  35889147
    d hpfs - ntfs              0  1  1  5182 254 63  83264832 [win_xp]
    d hpfs - ntfs              0  1 32  5182 254 63  83264801
    d hpfs - ntfs          2234  1  1 21371 254 63  307451907 [archive]
    d hpfs - ntfs          5183  1  1 24320 254 63  307451907 [archive]

    structure: ok.  use up/down arrow keys to select partition.
    use left/right arrow keys to change partition characteristics:
    *=primary bootable  p=primary  l=logical  e=extended  d=deleted
    keys a: add partition, l: load backup, t: change type, p: list files,
        enter: to continue
    ntfs, 42 gb / 39 gib

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

    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org

    disk /dev/sda - 500 gb / 465 gib - chs 60801 255 63
        partition              start        end    size in sectors
    d hpfs - ntfs              0  1  1  2233 254 63  35889147
    * hpfs - ntfs              0  1  1  5182 254 63  83264832 [win_xp]
    d hpfs - ntfs              0  1 32  5182 254 63  83264801
    d hpfs - ntfs          2234  1  1 21371 254 63  307451907 [archive]
    l hpfs - ntfs          5183  1  1 24320 254 63  307451907 [archive]

    structure: ok.  use up/down arrow keys to select partition.
    use left/right arrow keys to change partition characteristics:
    *=primary bootable  p=primary  l=logical  e=extended  d=deleted
    keys a: add partition, l: load backup, t: change type, p: list files,
        enter: to continue
    ntfs, 157 gb / 146 gib

    Жмем enter.

    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org

    disk /dev/sda - 500 gb / 465 gib - chs 60801 255 63

        partition                  start        end    size in sectors
    1 * hpfs - ntfs              0  1  1  5182 254 63  83264832 [win_xp]
    2 e extended lba          5183  0  1 24320 254 63  307451970
    5 l hpfs - ntfs          5183  1  1 24320 254 63  307451907 [archive]

    [  quit  ]  [ write  ]  [extd part]
                          write partition structure to disk

    testdisk вывел структуру pt, которую нам предстоит записать в mbr. write!

    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org

    write partition table, confirm ? (y/n)

    Нас в последний раз спрашивают, хорошо ли мы подумали? Да, то есть y.

    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org

    you will have to reboot for the change to take effect.

    [ok]

    Чтобы всё заработало, надо будет перезагрузиться. Жмем ok. Выходим на уровень вверх.

    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org


    disk /dev/sda - 500 gb / 465 gib - chs 60801 255 63

    [ analyse  ]  analyse current partition structure and search for lost partitions
    [ advanced ]  filesystem utils
    [ geometry ]  change disk geometry
    [ options  ]  modify options
    [ mbr code ]  write testdisk mbr code to first sector
    [ delete  ]  delete all data in the partition table
    [ quit    ]  return to disk selection

    note: correct disk geometry is required for a successful recovery. 'analyse'
    process may give some warnings if it thinks the logical geometry is mismatched.

    Жмем quit.

    testdisk 6.3, data recovery utility, march 2006
    christophe grenier <grenier@cgsecurity.org>
    http://www.cgsecurity.org

      testdisk is free software, and
    comes with absolutely no warranty.

    select a media (use arrow keys, then press enter):
    disk /dev/hda - 120 gb / 111 gib
    disk /dev/sda - 500 gb / 465 gib

    [proceed ]  [  quit  ]

    note: disk capacity must be correctly detected for a successful recovery.
    if a disk listed above has incorrect size, check hd jumper settings, bios
    detection, and install the latest os patches and disk drivers.

                                      quit program

    И еще раз quit.

    testdisk exited normally.
    you have to reboot for the change to take effect.
    root@rozik3:~# reboot

    Перезагружаемся... Еще раз ориентируемся на местности:

    root@rozik3:~# fdisk -l

    disk /dev/sda: 500.1 gb, 500107862016 bytes
    255 heads, 63 sectors/track, 60801 cylinders
    units = cylinders of 16065 * 512 = 8225280 bytes

      device boot      start        end      blocks  id  system
    /dev/sda1  *          1        2234    17944573+  7  hpfs/ntfs
    /dev/sda2            2235      21372  153725985    f  w95 ext'd (lba)
    /dev/sda5            2235      21372  153725953+  7  hpfs/ntfs

    disk /dev/hda: 120.0 gb, 120059362816 bytes
    255 heads, 63 sectors/track, 14596 cylinders
    units = cylinders of 16065 * 512 = 8225280 bytes

      device boot      start        end      blocks  id  system
    /dev/hda1              1          65      522081  82  linux swap
    /dev/hda2              66        1340    10241437+  83  linux
    /dev/hda3  *        1341      14468  105450660    7  hpfs/ntfs
    /dev/hda4          14469      14596    1028160    c  w95 fat32 (lba)

    Похоже на правду. Нам нужен /dev/sda5 - там лежат каталоги, нужные заказчику. Пробуем смонтировать /dev/sda5, не забывая, что раздел виндовый, и юзер обыкновенный не брезгует кириллицей в именах каталогов, поэтому:

    root@rozik3:~# mount -o iocharset=koi8-r /dev/sda5 /mnt/hd

    mount не ругается. Наши шансы стремительно растут :)

    root@rozik3:~# cd /mnt/hd
    root@rozik3:/mnt/hd# ls
    book/  games/      install/  office\ 2003/  recycler/                    windowsxp/    Хранение\ документов/
    film/  imagedrive/  music/    pictures/      system\ volume\ information/  ДОКУМЕНТАЦИЯ/

        yes!

    root@rozik3:/mnt/hd# cp -r ДОКУМЕНТАЦИЯ /root
    root@rozik3:/mnt/hd# cp -r Хранение\ документов /root

    Собственно, всё :) .

    Итоги или послесловие.
    Можно было бы возрадоваться успеху свободного ПО в деле датарековери на неродном для Линукса поле боя, но на всякую цистерну мёда найдется своё ведро дёгтя :) . Мы недаром вели логи копирования. Впоследствии, при изучении логов мы увидели, что львиная доля дефектов на исследуемом накопителе пришлась на системный раздел, в том числе крепко досталось и mft. Все попытки ради эксперимента смонтировать или фиксануть  /dev/sda1 окончились неуспехом с соответствующими пожеланиями :) используемых в этом нелегком деле программ.

    root@rozik3:~# mount -o iocharset=koi8-r /dev/sda1 /mnt/hd
    mount: wrong fs type, bad option, bad superblock on /dev/sda1,
          missing codepage or other error
          in some cases useful info is found in syslog - try
          dmesg | tail  or so

    root@rozik3:~# ntfs-3g /dev/sda1 /mnt/hd -o force
    failed to load $mft: input/output error
    failed to startup volume: input/output error
    failed to mount '/dev/sda1': input/output error
    ntfs is inconsistent. run chkdsk /f on windows then reboot it twice!
    the usage of the /f parameter is very important! no modification was
    made to ntfs by this software.

    root@rozik3:~# ntfsfix /dev/sda1
    mounting volume... failed to load $mft : input/output error
    failed to startup volume : input/output error
    failed
    attempting to correct errors... failed to load $mft : input/output error
    failed
    failed to startup volume : input/output error
    volume is corrupt. you should run chkdsk.

    Использование же обычного chkdsk уже в "самой дружественной ОС" восстановило валидность раздела и дало доступ к большинству файлов с остальными пользовательскими данными (системные файлы в таких ситуациях зачастую повреждаются, но и ценности они особой не представляют), даже без применения сторонней датарековери проприетарщины.

    Не следует забывать, что в нашей ситуации копировщики работают через системные драйверы того же ide-контроллера хоста с включенным на всю катушку udma, что в данной ситуации зачастую ведет к неправильной интерпретации зависаний или таймаутов дефектного накопителя как однозначных ошибок. Что и подтверждается сравнительным копированием платным копировщиком, написанным для dos, работающим непосредственно через порты ide-контроллера хоста и использующим свои алгоритмы управления скоростью копирования (в том числе и в udma режимах) и вычитыванием. Платный копировщик дал вчетверо меньше ошибок. Кроме того, автор ничего не знает о средствах первичной диагностики винчестеров под Линукс, способных выводить карту диска или хотя бы график чтения, аналогичных тем же mhdd, victoria и vivard для dos. Поэтому в описанном случае пришлось опираться сугубо на значения smart-атрибутов и собственный опыт и вносить корректировки в процесс снятия данных уже по ходу работы, что в отдельных случаях может быть довольно рискованным.

    Тем не менее, в завершение, хочется с удовлетворением отметить, что, в отличие от "дружественной ОС" под котрую и за деньги мало чего надёшь путного, для Линукса существуют мощные, явно написанные со знанием дела, открытые и свободные приложения, способные бороться с весьма тяжелыми физповреждениями накопителей, а также софт с быстрыми и грамотно разработанными алгоритмами поиска утерянных первичных логических стуктур накопителей, вовсе не являющихся нативными для Линукс.

    Автор не ставил перед собой задачи показать, что под Линуксом можно "рубать капусту" :) (хотя мы предметно увидели, что и это возможно :) ) , а хотел поделиться с сообществом себе подобных :) некоторыми наработками в правильном профессиональном подходе к восстановлению данных и показать, что в Линуксе rip значит вовсе не rest in peace, а recovery is possible :) !

    Виталий Розизнаный aka rozik специально для rlab.ru
PMПисьмо на e-mail пользователю
Top
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:

Опции темы Ответ в темуСоздание новой темыСоздание опроса