» Восстановление разделов и информации на HDD (часть 3)

azalon
Если бы были проблемы со шлейфом, были бы интерфейсные ошибки. Но винт не зарегистрировал ни одной интерфейсной.

Насчет WinHex. Не видит он ничего. Потому как затерто начало раздела нафиг...

Насчет дампа. Уже гораздо лучше. Первые 200 секторов (0...199) провафлены. Зато после них - вожделенный FAT. Видно, что раздел имел 34 reserved sectors. Итого: улетел бутсектор и его копия и начало первой таблицы. Вспоминайте размер кластера. Кроме того, нужно найти вторую таблицу и воссьановить начало первой. Сделайте поиск Alt+Ctrl+F, начиная с начала раздела. Строка F8FFFF0F либо F8FFFF7F (пробуйте обе). Долго можно не искать, максимум - минуту...две. Включите чекбокс Cond offset mod 512 = 0, иначе много туфты найдется. В начале таблицы должно быть примерно так:
F8 FF FF 0F FF FF FF FF FF FF FF 0F 04 00 00 00
05 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00
...
Сделайте дамп примерно 300 секторов, начиная с найденного и включите в имя файла номер сектора (см. внизу в строке состояния). Если повезет, завтра вечером будем делать бутсектор и оживлять первую таблицу. FAT - не NTFS: если вторая таблица и остальное (после нее) живое, то и раздел можно легко вернуть, главное - аккуратно.

Antech
F8FFFF0F нашло в 3 местах:
http://slil.ru/25974061
http://slil.ru/25974062
http://slil.ru/25974063

сделал дамп начальных данных с незаконченного образа, сделанный при первой попытке (когда отключился винт) Может поможет.
http://slil.ru/25974067

azalon
ОК, спасибо. Вечером, надеюсь, посмотрю.

Постарайтесь вспомнить размер кластера. Хотя можно будет попробовать методом тыка, благо стандартных sectors per cluster не много.

azalon
Посмотрел дампы.

1. Дампы таблиц.
Очевидно, что только первый файл (сектор раздела 16005) - это начало таблицы. Другие файлы - просто случайное совпадение.

2. Дамп начала раздела клона.
А вот здесь наблюдаем очень интересную вещь. Классика жанра. Начало раздела (на 7.8 GiB) в порядке, но оно смещено на 20 байт вниз. Такое бывает из-за аппаратных глюков, плавали-знаем...
Соответственно, восстановление сводится к следующему:
1. Отключите пострадавший винт физически и сделайте хорошую проверку системы. Память - МемТестом86 хотя бы час погонять, блок питания - померить хоть тестером напряжения, если хреновый бренд - заменить на уважаемый типа FSP, возможно, есть смысл подозревать IDE контроллер (вспухшие кондеры на матплате, к примеру) - тогда нужно ремонтировать/менять мать или купить PCI IDE контроллер.
2. Подключите пострадавший винт и откройте его в WinHex. Перейдите к началу раздела. Аналогично - на клоне.
3. На клоне перейдите по смещению 20 байт (14 hex). Это вторая строка, позиция 4. Вы должны видеть там, куда указывает курсор, байты EB 58 90 и т.д. Нажмите Alt+1.
4. Перейдите на 500 секторов вниз (примерно), пользуйте для этого Alt+G. Нажмите Alt+2. Теперь у Вас выделен блок для имплантации на пострадавший раздел. Скопируйте его Ctrl+C.
5. Перейдите к началу раздела физического диска. Вы доджны видеть там уже знакомые нам мусорные байты 40 10 60 00 00 08 04 04 и т.д. Сейчас они умчатся в вонючую даль . Нажмите Ctrl+B, чтобы заменить эту шнягу на здоровое начало раздела. Нажмите Ctrl+S для сохранения.
Внимание. Пункт 5 - это запись. Будьте очень аккуратны. Проверьте, что курсор находится в начальном байте нужного раздела. Не запишите случайно "не туда".

Собственно, после переоткрытия физического в WinHex раздел должен нормально открываться через Access - Partirion - Open.

Добавлено:
Так значит, я немного лоханулся. На клоне и дальше есть смещения, так что предыдущая инструкция (начиная с п. 2) отменяется. Поэтому лучше будет скопировать начало таблицы из файла "16005":
1. Откройте раздел на клоне и сместитесь на 20 (0x14) байт. Нажмите Alt+1.
2. Переместитесь на 34 (0x22) сектора вниз. Нажмите Alt+2, Ctrl+C.
3. Перейдите в начало раздела на физическом диске.
4. Нажмите Ctrl+B.
5. Откройте файл 16005.
6. Нажмите Ctrl+A, Ctrl+C.
7. Перейдите в начало раздела на физическом винте. Сместитесь на 34 (0x22) сектора. Нажмите Ctrl+B, Ctrl+S.

Перед экспериментом желательно снять дамп первых 100000 секторов раздела на физическом диске (выкладывать его не надо).

Если Вы уже скопировали 500 секторов начала раздела с клона, Вам нужно поправить первую таблицу FAT. Для этого скопируйте 500 секторов, начиная с сектора 16005 раздела на физическом диске в этот же раздел, начиная с сектора 34. Таким образом Вы замените начало первой таблицы на копию, где, я надеюсь, минимум глюков. Пожалуйста, будьте аккуратны.

Программы для восстановления данных с HDD

http://www.3dnews.ru/software/unerase-software

Antech
Перемещение на 34 сектора = смещению 43FF от начала раздела?
На клоне нет возможности перемещатся по секторам, только по страницам.

azalon
Перемещение на 34 сектора = смещению 43FF от начала раздела?
34*512=17408 dec=4400 hex. Но в данном случае правильнее действительно на 43FF (я просто дал 34 сектора для ровного счета) - тогда не будет скопирован первый байт первой таблицы FAT, который нам с клона и не нужен (вы скопируете его из второй таблицы физического). Когда копируете начало раздела с клона, ошибка в размере фрагмента на +/- пару секторов не имеет значения: немного ниже ничего существенного нет, а немного выше - таблица, которая будет потом взята из копии на физическом. Кстати, второе глючное смещение, которое я обнаружил, расположено на 232 (dec) секторе от начала раздела клона (смещение 1D014h байт, размер 12 (0Ch) байт), и дальше в дампе клона глюных смещений нет (в реальности они могут быть, т. к. одна таблица у Вас 15971 секторов, а дамп клона - 301 сектор минус 34 reserved sectors). Хинт: чтобы увидеть параметры бутсектора, в WinHex поставьте курсор в бутсектор раздела (на физическом, когда скопируете по "инструкции") и нажмите Alt+F12, Boot Sector FAT32.

Antech
Комп проверил, взял новый шлейф. Сделал все по обновленной инструкции. Раздел в WinHex открылся. Но были ошибки:

Hard disk 2, Partition 1: Invalid, corrupt or simply unexpected directory entry found at offset 665D5000.
Notices about directly following invalid entries have been suppressed.
Hard disk 2, Partition 1: Invalid, corrupt or simply unexpected directory entry found at offset 665D5080.
Notices about directly following invalid entries have been suppressed.
Hard disk 2, Partition 1: Invalid, corrupt or simply unexpected directory entry found at offset 665D5140.
Notices about directly following invalid entries have been suppressed.
Hard disk 2, Partition 1: Invalid, corrupt or simply unexpected directory entry found at offset 665D5340.
Notices about directly following invalid entries have been suppressed.
Hard disk 2, Partition 1: Invalid, corrupt or simply unexpected directory entry found at offset 665D5560.
Notices about directly following invalid entries have been suppressed.
Notices about invalid directory entries are no longer displayed.

azalon
В Винде раздел открывается?

Насчет ошибок... Глюков было много, так что не удивительно, что там и в других местах не все в порядке. Не затруднит скинуть дамп 100 секторов, начиная с сектора 3354279 (0x332EA7) от начала раздела? (Это смещение 0x665D5000 байт от начала раздела минус один сектор).

Antech
Раздел в винде виден, но нету некоторых папок и файлов.

дамп: http://slil.ru/25976653

azalon
В дампе нет ничего похожего на аталог, хотя WinHex недоволен directory entry. Либо это разрушенный каталог, либо дамп не с того сектора. Мы не знаем, относительно чего WinHex сообщает смещения: начало раздела или начало диска. Если Вы брали смещение от начала диска, попробуйте еще один дамп со смещением от начала раздела, и наоборот.

нету некоторых папок и файлов
Это уже сложнее для дистанционного. Можно попробовать посмотреть на каталоги... Попробуйте найти небольшой каталог, где исчезли файлы/подкаталоги. В WinHex правая кнопка на каталоге - GoTo Beginning of directory. Снимите дамп секторов на 100, начиная с показанного сектора. Сообщите наименования потерянного файла или подкаталога, а также наименования существующих файлов/подкаталогов (для контроля).
Вы хорошо понимаете в теме, Вы могли бы самостоятельно покопать, т.к. это удобнее и быстрее. Каталоги в FAT - это последовательности 32-байтных структур, каждая из которых называется directory entry и описывает подкаталог или файл. Все каталоги, кроме корневого, начинаются двумя directory entry с именами "." (указывает на сам каталог) и ".." (указывает на родительский каталог). Подробнее можно почитать в мануале FATGEN (с. 22, FAT Directory structure, табл. на с. 23) с сайта Микрософта. Вам нужно попытаться найти глючные смещения в структуре каталога. Однако, тут могут быть и не смещения, а перетирание мусором - как 200 секторов в начале раздела. Тогда уже вручную вряд ли восстановится. Теоретически можно в таком случае попытаться через Check Disk, но он может такое напортачить, что лучше не пробовать... Тем более, причина глюков неизвестна!

вроде много прочитал про восстановление инфы, только вот несмотря на мой опыт не как немогу понять как править вручную партицию, если есть с картинками то было бы неплохо, шапки в теме особо не помогли, особенно вот эта http://www.derstein.ru/good/good.html устарела. Хотя будет полезна новичкам, кто в хардах не очень. Очень бы хотелось это узнать. Кстати напишите пожалуйста мне в пм, что за хороший популярный форум есть за который дают бан. Более полезную инфу всетаки узнал из ваших сообщений. Как говорят другие что testdisk не заменит ручное восстановление.

djremix
Ответил в ПМ.

как править вручную партицию
Это слишком общий вопрос. Соответственно, стандартный общий ответ.

Мануалы:
1. Intel-style таблицы разделов
2. Описание файловой системы FAT32 от Microsoft (FATGEN)
3. Описание файловой системы NTFS (Крис Касперски)
4. Описание файловой системы NTFS (Linux NTFS)

Инструменты:
1. DMDE
2. WinHex

Antech

Цитата:

как править вручную партицию
Это слишком общий вопрос. Соответственно, стандартный общий ответ.

Мануалы:
1. Intel-style таблицы разделов
2. Описание файловой системы FAT32 от Microsoft (FATGEN)
3. Описание файловой системы NTFS (Крис Касперски)
4. Описание файловой системы NTFS (Linux NTFS)

есть 2ой и 4 пунк на русском, а то в english, не очень силен, сами понимаете если переводчиком переводить - то переводит криво

djremix
2ой и 4 пунк на русском
Вместо второго можете почитать Статью Фролова.
Вместо четвертого - не знаю. Может быть, Вам поможет книга "Криминалистический анализ файловых систем" Б. Кэрриэ (не помню, откуда скачивал). Там довольно подробно описано.

Помогите с проблемой:
У меня стоял апаратный RAID-1 из 2-х SCSI дисков по 36Gb, на котором был один раздел NTFS.
В один прекраснвй день, после включения компьютера Windows 2000 server, стоявшая на нем, выдала BSOD 0x0000007B.
Полез в настойки RAID-массива, дабы отключить рейд, и случайно (кривые руки, халатность...) провел инициализацию, которая привела к сами понимаете чему ("зануление" таблицы разделов и возможно чегото еще).
Далее с дисками ничего не делал. Я знаю что информация на дисках осталась (возможно не вся).
Теперь вопросы:
1. Какие данные были удалены при инициализации?
2. Могу ли я восстановить разделы на этих дисках и как? (если да то какой метод или программа лутше, а если нет то что делать?)
3. Имеет ли смысл объеденять диски обратно в RAID-1 при восстановлении?(с какого диска восстанавливать данные?)
4. Каковы наиболее вероятные причины BSOD 0x0000007B и как лутше от него избавиться (на этот вопрос отвечать не обязательно, хотя интересно узнать ваше мнение).

zimer
Какие данные были удалены при инициализации?
Сделайте дамп первых 1000 секторов диска и залейте на zalil.ru или filekeeper.org. Скажу, что затерто, а что - нет. Если повезло, то улетела только MBR и вернуть раздел можно за 5 минут в WinHex. Если потерто начало раздела (он как пить дать в 63 секторе начинался), то тут уже зависит от везения. Обычно при формате Виндой MFT расположена в начале раздела (4 кластер) или в ~3 ГБ от начала раздела (кластер 786432). В первом случае при потертом начале раздела - плохо, как Вы понимаете. Во втором - ничего особенного: бутсектор переносится из конца раздела (Винда обычно пишет его туда при форматировании), и раздел будет работать (естественно, файлы, расположенные в начале раздела, потрутся, зато ФС и остальные файлы будут живы).

Имеет ли смысл объеденять диски обратно в RAID-1
Нет, лучше восстановить на одном диске, а потом - продублировать на другом. Второй диск будет как бы бэкап.

Цитата:

Сделайте дамп первых 1000 секторов диска ......

Первые 39936 секторов - нули

Зделал образ диска, поработал TestDisk'ом, MFT - капец, запустил chkdsk, посмотрю что выдаст.
(Чуствую прийдется все с нуля ставить, хорошо что все нужные данные в бэкапе отдельно лежат)

zimer

Цитата:

Первые 39936 секторов - нули

Так может поэтому-то никто посекторную копию снимать не хотел?

В дополнение к своему предыдущему сообщению:
Первые 39936 секторов занимают 19.5 Мбайт места. $MFT у меня находился в начале и содержал информацию о 270 тыс. файлах. Если я правильно понимаю(из недавно прочитаного), каждая запись о файле в среднем составляет 1 Кбайт и в итоге я потерял записей о 19.5 тыс. файлах (на самом деле чуть меньше).
В начале обычно находятся записи о файлах операционной системы, Program Files, Documents and Settings. Вот они то и должны попасть под раздачу первыми, так как были созданы первыми и файлы в них почти не удалялись. Это очень радует, ведь в этих директориях почти ничего ценного не содержалось.
После проверки утилитой Check Disk (chkdsk) образовалась папочка found.000 размером в 520 Mb с кусками пропавшей инфы. Как я и подозревал, системные директории пропали. Подавляющее большинство полезных данных сохранилось, а вот систему прийдется ставить и настраивать с нуля, чего я как раз и не хотел делать. Пробовать восстанавливать 19.5 тыс. файлов без необходимого куска $MFT очень геморно, поэтому возиться я с ними не стал (все нужные данные ежедневно бэкапятся на отдельный диск).
Так что не играйтесь дети с инициализацией RAID-массивов и с Rebuild'ом тоже будьте осторожны.

zimer
каждая запись о файле в среднем составляет 1 Кбайт
Размер файловой записи указан в бутсекторе. Хотя фактический размер файловой записи
различен для разных записей, каждая запись всегда занимает один и тот же объем (стандартно 2 сектора, по-другомй не видел), просто эти 2 сектора используются не полностью (запись может также состоять из нескольких, дополнительные записи описаны в атрибуте 0x20 и называются "расширенные", насколько помню, но все равно аллоцированный размер каждой из записей - один и тот же).

Был веник с 2 логическими разделами C и D. На него ошибочно начали установливать Windows в unattended режиме, который форматит диск и ставит на него винду. В итоге сейчас на диске виден 1 логический раздел C, на нем видны удаленная папка Windows и pagefile.sys. Смотрел с помощью Active Partition Recovery из подборки Hiren's Boot CD.
Нужна инфа с бывшего логического раздела D.
Посоветуйте как лучше действовать.
Спасибо.

flex2002
Ну неужели трудно глаза поднять чуть-чуть -- в шапку
Цитата:

Обращаясь в тему за помощью, обязательно укажите информацию о диске: тип, емкость, способ подключения, информацию о разделах, SMART винта из MHDD / Victoria / HDDScan, наименование и мощность БП, возраст БП, результаты MemTest86, версию ОС и сервис-пака, а также обстоятельства краха - честное слово, толковым запросам и отвечать приятно. Здесь телепатов нет...

Можно же прикинуть, что гадать тут мало кто может. Кстати, много вопросов остаются без ответов именно по этим причинам -- просто надоедает

Цитата:

Можно же прикинуть, что гадать тут мало кто может

сенкс. когда соберу инфу, попробую снова обратиться

В твоём случае ясно, что нет аппаратных проблем, поэтому и не надо делать вот эти
Цитата:

SMART винта из MHDD/Victoria/HDDScan, наименование и мощность БП, возраст БП, результаты MemTest86

а остальное инфо не повредит

Цитата:

остальное инфо не повредит

Samsung MP0402HTBD - 40 гиговый гоутбучный винт, установлен соответственно в ноуте,
подключен по IDE, разбит был С - 9 гиг, D - остальные ~ 30 гиг
Сейчас на нем после случайной установки винды в автоматическом режиме получился 1
раздел емкостью 39 гиг.
Винда, которая начала ставиться, не грузится. В развернутом состоянии она обычно занимает около 1 гига, из чего я делаю вывод что затерт максимум первых гиг диска. А мне нужна инфа с диска D, который начинается с 10-го гига.
Так как веник в ноуте торчит, то довольно проблематично его подключить к другой системе чтобы снять образ диска или подключить через wmware, чтобы безопасно в нем ковыряться. Но я так понимаю, все-таки имеет смысл сделать копию

flex2002
Цитата:

В развернутом состоянии она обычно занимает около 1 гига, из чего я делаю вывод что затерт максимум первых гиг диска

Правильно прикидываешь. А снять образ всё-таки не повредит. Попробуй R-Studio

flex2002
Сделайте поиск разделов в DMDE (есть версия для DOS).
Так или иначе, для комфортной работы лучше обзавеситись каким-нибудь LiveCD с Виндой. Тогда и образ без проблем сделаете (в R-Studio).

В развернутом состоянии она обычно занимает около 1 гига
Вопрос - в том, как этот 1 гиг размазан по винту. И не задет ли бутсектор второго раздела. Винда иногда весьма совеобразно фрагментирует файлы, даже если на разделе полно пустого места и исходно нет фрагментации вообще.

Цитата:

LiveCD с Виндой

типа загрузиться с live cd и сделать образ на сетевой диск?
локально на комп ведь некуда его сбросить
и Live CD ничего не потрет, когда грузиться будет?

flex2002
LiveCD может потереть. Но что еще делать, если к другому компу подключить винт проблематично? Ну можно еще Linux LiveCD использовать, он ничего не потрет. Образ сделаете из консоли командой dd, например:
dd if=/dev/sda of=/dev/sdb
Чтобы определить, что подставлять вместо sda и sdb, сделайте fdisk -l (выведет список устройств, там посмотрите их обозначения). Не перепутайте: if - источник, of - приемник. Если сделате образ на внутренний винт вместо внешнего винта, восстанавливать будет нечего. Как сделать образ по сети в Линуксе, я не знаю.