» Восстановление разделов и утерянной информации на HDD

KLASS


Спасибо, вроде совет дельный. Правда попробовать пока не удастся. Ответа долго дожидался - сделал по другому...разбил партицию на две как раз в месте сбоя и вынес этот участок в unallocated.

Есть еще вопрос, если позволите. Почему вообще диск отказывается работать (помогает только отключение питания) когда идет доступ к данному кластеру или точнее сектору диска. На сколько я знаю, беды физические не приводят к таким отключениям. Даже не знаю, что делать ((( Так диск работает нормально. Нашел 20 софтбедов полечил все регенетаром и все работает как часики. а с этим кластером два дня мучалсся пока не изолировал его в unallocated

KUMICH

Цитата:

Правда попробовать пока не удастся.

Я делал, работает. Единственно, что делал это на диске здоровом, а вот как WinHex среагирует на бэд, не ведаю, он ведь при открытии тома, сканит чего то, может нарваться на этот бэд и встать. На этот случай найди старый DiskEditor от Нортона, с дискеты грузись и также открывай лог-диск и ФАТ, помоему через меню Object. Ищи кластер и вводи букву "B", программа сразу переведет кластер в <BAD>.

Цитата:

сделал по другому...разбил партицию на две как раз в месте сбоя и вынес этот участок в unallocated.

Тоже можно, старый, дедовский способ.

Цитата:

Почему вообще диск отказывается работать

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

KLASS
ответ на конкретный вопрос конкретному пацану...

Цитата:

Что есть: "приведении в соответствие КС"?

Это есть слдеующее. Поскольку нас интересует восстановление инфы из софт-бэда, а неправильная КС мешает нормально прочитать эту инфу стандартными средствами, нужно сделать следующее.
1. Вариант. Программа считывает указанный ей дефектный
сектор указанное количество раз и складывает его в файл с именем=№
сектора и расширением=№ попытки. Если использовать не 20h, а 22h, то кроме сектора мы получим еще и ecc, правда, утверждать, что она будет верной - я не возьмусь, но все-же, учитывая разницу в длинне (512 vs 4 байт), есть вероятность, что она
нормальна. Появляется шанс написать некую программу, которая будет делать
примерно следующее (кусок ТЗ):
Есть N копий плохого сектора по 512 байт, разных. Задача - сравнить их
между собой, найти совпадающие куски и несовпадающие, разбить на блоки
(в идеале - по границам совпадающих кусков, но можно и просто разбить на
3-4-5-.. равных кусков), перебрать все варианты сбора разных кусков в один
сектор с подсчетом ECC и выдать тот, у которого ecc совпадет со считанным
с винта. Вероятнее всего, совпадающим кускам можно верить, а в разных -
мусор. ECC позволяют определить, какой символ в области данных (или даже в
области ECC) неверен и исправить его на верное значение. В случае двух
и более ошибок избыточности кода уже не достаточно, можно только определить,
где ошибка. Процедура вычислений стандартна. Если всего 4 байта, то это уже
CRC, которая не поможет ни восстановить правильные значения, ни определить
местоположение ошибки. .
2. Вариант. Дать команду винту через любой ata-терминал на отключение проверки ЕСС. После этого просто копируются данные, возможно с ошибками. Потом данные копий скалдываются по mod2 и получается корректная инфа.
3. Вариант. Используя другой софт.
PCHDD
hdd regenerator
etc

help777
Что то меня берут смутные сомнения...

help777
1. А откуда цифра 4 байта? И откуда уверенность про "процедура вычислений стандартна"? А если проделать эксперимент: записать сектор одним и тем же содержимым на разных винтах, прочитать потом лонгом и сравнить "хвосты"? Я вот только что сравнил на Фуджике MPG и IBM DTLA. Она, конечно, может и стандартна, но результат разный
2. Почему это должна получиться корректная инфа? Просто статистикой? Так это и для исправных секторов не всегда получится.
3. А что в этом софте такого магического? Особенно в регенераторе .

LeoT

Цитата:

1. А откуда цифра 4 байта? И откуда уверенность про "процедура вычислений стандартна"? А если проделать эксперимент: записать сектор одним и тем же содержимым на разных винтах, прочитать потом лонгом и сравнить "хвосты"? Я вот только что сравнил на Фуджике MPG и IBM DTLA. Она, конечно, может и стандартна, но результат разный

Процедура расчета - стандартна, а блоки коррекции ошибок на разных винтах возможно могут отлиичаться. а 4 байта=32бит

Цитата:

2. Почему это должна получиться корректная инфа? Просто статистикой? Так это и для исправных секторов не всегда получится.

Не просто статистикой. Есть такая функция в схемотехнике - Исключительное ИЛИ ака сложение по mod2 в дискретной математике ака XOR в ассемблере. Она участвует в любой схеме коррекцииошибок при передаче данных (хоть по телефонной линии, хоть по шлейфу иде-кабеля).

Цитата:

А что в этом софте такого магического? Особенно в регенераторе

Это лучше спросить у авторов. PCHDD имеет возможность восстанавливать инфу из бедов, HDD regenearator помог кому-то из ветки, даже по-моему в HDDspeed есть media format with try recovery bad block. Какая прога поможет в конкретном случае - нужно пробывать. Приведенная выше Readbad - тоже копирует данные используя 22h как описано в посте выше.

To help777:

Цитата:

При загрузке ОС производит запись на винт

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

Цитата:

тестдиск можно запустить из доса с дискетки

Знаю. А из сейфмода можно и не только тестдиск запустить.

Цитата:

приведите точный код ошибки

Код: STOP: 0x0000000A (0x00000000, 0x00000002, 0x00000001, 0x8042DE20)
IRQL_NOT_LESS_OR_EQUAL
Address 8042DE20 call at 80400000; DateStamp 3ee6c002 - ntoskrnl.exe

CocKain

Цитата:

STOP: 0x0000000A (0x00000000, 0x00000002, 0x00000001, 0x8042DE20)

Ошибка «Stop error 0x0000000A (Stop 0x0A)» указывает на то, что в режиме ядра была предпринята попытка обратиться к файлу подкачки на уровне внутреннего запроса (Internal Request Level, IRQL) процесса, но этот уровень оказался слишком высоким. Обычно эта ошибка возникает при использовании неправильного адреса памяти драйвером. Другой причиной может являться несовместимый драйвер устройства, проблема с оборудованием или несовместимое программное обеспечение.

Мелкософт советует избавляться от них так:

Если ошибка «Stop 0x0A» продолжает появляться, следует выполнить следующие действия.
1. В процессе загрузки установки нажмите клавишу F5 при появлении сообщения о проверке программой установки аппаратной конфигурации компьютера. Затем появится приглашение задать тип компьютера и уровень аппаратных абстракций (HAL). Например, для компьютера с одним процессором выберите тип «Стандартный компьютер».
2. Отключите следующие параметры в настройках CMOS компьютера. Инструкции см. в документации по оборудованию или у производителя оборудования.• Все виды кэша, включая кэш второго уровня ЦП, кэширование BIOS, внутреннее и внешнее кэширование, а также кэширование записи на контроллере жестких дисков
• Использование «теневой» памяти
• Plug and Play
• Все средства защиты от вирусов, встроенные в BIOS

3. Удалите все платы адаптеров, отключите все устройства, которые не являются необходимыми для запуска компьютера и установки Windows, включая:• Сетевой адаптер
• Внутренний модем
• Звуковую плату
• Дополнительные жесткие диски (для завершения установки требуется хотя бы один)
• Дисковод компакт-дисков или DVD-дисков (при установке с локального жесткого диска)

4. При использовании адаптера SCSI выполните следующие действия. Дополнительные сведения см. в документации по оборудованию.• Получите наиболее позднюю версию драйвера для Windows у поставщика оборудования.
• Отключите синхронное согласование на контроллере SCSI.
• Проверьте правильность терминирования и распределения идентификаторов устройств SCSI.
• Отключите все устройства SCSI, кроме одного жесткого диска (при загрузке с этого диска или установке на него).

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

6. Проверьте модули памяти SIMM (оперативная память) в компьютере. Дополнительные сведения см. в документации по оборудованию.• Удалите несоответствующие модули памяти SIMM; все модули должны иметь одинаковую скорость. Например, 60 нс или 70 нс.
• Запустите системный тест на памяти и удалите все недействующие модули памяти SIMM.
• Протестируйте различные модули SIMM, если они доступны.

7. Выясните у изготовителя компьютера или материнской платы о наличии типичных проблем, связанных с работой или установкой Windows XP. Изготовители могут предоставить помощь по следующим вопросам.• Выполнение на компьютере диагностического теста.
• Обновление BIOS, если возможно.

Цитата:

[/q]
help777
1.
[q]Процедура расчета - стандартна, а блоки коррекции ошибок на разных винтах возможно могут отлиичаться. а 4 байта=32бит

Описанный выше эксперимент показывает, что отличаются. Документация на конкретные реализации у разных производителей - недоступна. А при чтении лонгом отдается 512 байт данных + 8 байт "хвост" до снятия drq. Причем это не те байты, которые реально используются системой ЕСС коррекции. Например, в мануале на Квантум EL написано о 4 cross-check bytes и 32 ECC bytes.
2. Предлагается читать сектор много раз и ксорить каждый вариант с каждым, пока не получится 0, и тогда считать данные достоверными? Это и есть "статистика". Это IMHO менее надежный способ, чем штатная система ЕСС, и вряд ли он поможет, когда не помогает ЕСС.
3. Они используют read long, регенератор вряд ли и его использует (но я не смотрел, так что не уверен, это просто общее впечатление о грамотности авторов данной программы), Hddspeed делает ремап (50h). А читать лонгом - это вариант для того, чтобы хоть что-то прочитать, но как показывает практика, достоверные данные таким способом получить очень маловероятно. Это уже неоднократно проверено, в разных реализациях, и многократно со сравнением в том числе. И вообще, все зависит от природы дефекта. На практике условие "физически сектор целый" не выполняется. Исключение - намеренное искажение байт ЕСС, например, вроде в mhdd есть команда makebad или что-то в этом роде (я так году в 97-98-м спорные винты по гарантии отправлял ). Но "в дикой природе" такое встречается редко.

help777
1.
Сдается мне, что у нас разные понятия о софт-бэдах, с чего, собссно, начался разговор. То, о чем ты говоришь, это, скорее, не софт-бэды (с битой КС), а сектора со слабым сигналом из которых еще хоть что-то читается. Предлагаю тебе проделать все, что ты выше написАл, создав у ся искуственно софт-бэд, используя MHDD.
2.

Цитата:

Дать команду винту через любой ata-терминал на отключение проверки ЕСС.

А ЧАВО это за команда?
3.

Цитата:

HDD regenearator помог кому-то из ветки

Ты о чем? Человек лишь избавился от софт-бэдов, но об спасении инфы разговора небыло. Это был skuzi
Вот его слова:

Цитата:

На диске были BAD-ы. CHKDSK их определила. HDDRegenerator их устранил (вот не ожидал!) и показывает отсутствие BAD-ов.

Цитата:

Приведенная выше Readbad - тоже копирует данные используя 22h как описано в посте выше.

Копирует, если речь о секторе со слабым сигналом, но в случае софт-бэда, записывает якобы "считанное" в файлы, но это не значит, что те файлы содержат какую то инфу. Они лишь имеют размер, по команде 20h=512байт, а по 22h (с параметром L)=516байт, но инфы там нет. Это тоже самое, как будто бы ты скопировал в редакторе диска сектор не содержащий инфы (т.е. забитый 00h). Размер то есть, а инфы тю-тю. Проделай, что я сказал в пункте 1 и убедись сам.

To help777:
Спасибо, конечно, но не стоило так беспокоиться, искать описания, тем более столь подробные.
Как я уже писал, проблему свою я решил - данные забрал. Что же до винчестера - обойтись без него можно, да и гудит он слишком громко (ему всё-таки четыре года уже!) Иногда заснуть мешает... Проблема скорее всего в микрософте, что неисправимо.
Останется как сувенир - последняя железка от первого компьютера ;)

Чем богаче язык, тем больше словоблудия. Предлагаю отречься от матерного выражения софт-бэд. Есть сектора читаемые и нечитаемые, последние, в свою очередь, делятся на те, которые можно вернуть в работу низкоуровневой записью в них и которые нельзя, стало-быть, reassign.

KLASS

Цитата:

Сдается мне, что у нас разные понятия о софт-бэдах, с чего, собссно, начался разговор. То, о чем ты говоришь, это, скорее, не софт-бэды (с битой КС), а сектора со слабым сигналом из которых еще хоть что-то читается. Предлагаю тебе проделать все, что ты выше написАл, создав у ся искуственно софт-бэд, используя MHDD

ок, специально проведу такой эксперимент и отпишусь сюда, но только чуток попзже. Сейчас сложно со временем


Добавлено:
ЗЫ. попробую написать письмо к автору hddreg и все-таки выяснить какие бэды восстанавливает программа и по какому алгоритму работает.

Прювет, ребята

У меня такой вопрос:

Есть сеть из 12-15 компов и есть сервер на котором хранятся образы primary партиций с winXP каждого из них. Так вот сейчас восстановление засореной винды происходит следующим образом: любой комп загружается с boot cd с winXPE, подключается удаленный диск сервера и через Norton Ghost восстанавливает партицию с сервера.

Так вот у меня такой вопрос: как можно автоматизировать эту систему восстановления партиций с сервера, что бы все компутеры восстанавливались одновременно.

Заранее спасибо .

Начинающий ламер

kabluk

Цитата:

как можно автоматизировать эту систему восстановления партиций с сервера...

ты не в ту ветку зашел, тебе в операционные системы


Цитата:

... что бы все компутеры восстанавливались одновременно.

А сервак выдержит такой траффик?

Доброго времени суток!

Уважаемые форумчане, помогите, плз! Приволок с работы домой диск Гнусмас на 40 гиг. Он стоит единственным диском у меня на рабчем компе. Разбит на три диска: boot -- 8 гиг (С:\ -- система и ничего кроме нее), затем extended part., на котором два логических диска: 5 гиг (D:\ -- вордовские файлы, текстовые DOSовские и прочая требедень) и третий диск на 25 гиг (E:\ -- архив программ, изошники, видеофайлы, громадный архив фоток и т.д.). На всех дисках NTFS. Система -- ХР SP2. Приключился следующий казус: после активного поиска тектовой информации в теле фотографий, нужные фото были скопированы в отдельную директорию. Из нее -- на флэшку. Затем при попытке удаления директории с ж.диска система сказала мне "стой" и зависла. После перегрузки первый и третий диски винта (H:\ и J:\) стали недоступны, хотя в проводнике отображаются с присвоенными буквами. Пропали метки томов (было DISK1_VOL1 стало просто Local Disk). Свойства говорят о файловой системе RAW, никаких других данных система не видет.


Пытался лечить chkdsk /f из консоли восстановления. Прога сообщила, что из-за множества ошибок не может выполнить операцию. Применил NTFSPro 5.0, но и она не спасла: не может примонтировать партицию. Партишн Мэджик сообщает об ошибке #1507 -- Bad file record signature. Но при этом прога видит разбивку на логические диски и информацию на них. Взял GetDataBack для NTFS и удачно слил все файлы с упавших дисков на домашний комп. Все хорошо, но у меня стоит задача оживить винт. Кто-то сталкивался с подобной проблемой, когда ни chkdsk, ни NTFSPro не могут достучаться к диску для лечения? Подскажите, плз, в каком направлении двигаться дальше?

BESA

Цитата:

Подскажите, плз, в каком направлении двигаться дальше?

chkdsk не работает потому что есть ошибки в таблице разделов. Возьми testdisk и вылечи винт

help777 Пытаюсь просмотреть список файлов. Получаю сообщение:

TestDisk 5.7, Data Recovery Utility, April 2005
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

* HPFS - NTFS 0 1 1 1021 254 63 16418367

Can't open NTFS filesystem: I/O error


Добавлено:
А вот инфа по самому диску:


TestDisk 5.7, Data Recovery Utility, April 2005
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdb - CHS 4870 255 63 - 38201 MB

Partition Start End Size in sectors
1 * HPFS - NTFS 0 1 1 1021 254 63 16418367
2 E extended LBA 1022 0 1 4869 254 63 61818120
5 L HPFS - NTFS 1022 1 1 1660 254 63 10265472 [DISK1_VOL2]
6 L HPFS - NTFS 1661 1 1 4869 254 63 51552522

BESA

Цитата:

Пытаюсь просмотреть список файлов. Получаю сообщение:
Can't open NTFS filesystem: I/O error

сначала нужно сохранить найденную таблицу разделов


Partition Start End Size in sectors
1 * HPFS - NTFS 0 1 1 1021 254 63 16418367
2 E extended LBA 1022 0 1 4869 254 63 61818120
5 L HPFS - NTFS 1022 1 1 1660 254 63 10265472 [DISK1_VOL2]
6 L HPFS - NTFS 1661 1 1 4869 254 63 51552522

После этого все данные будут доступны.

BESA

Цитата:

Свойства говорят о файловой системе RAW

Цитата:

Can't open NTFS filesystem: I/O error

Если диски видны в проводнике Таблица разделов исправна. Не видна файловая система на дисках, стало-быть, слетел бутсектор (возможно не только он, но и последующие). Посмотри в любом редакторе диска первый сектор томов, которые видны как RAW и сравни каждый с последним сектором тома (копия бутсектора). Если они не равнозначны, просто скопируй последний сектор на место первого, поставив курсор на первом байте первого сектора (не выделяя сам сектор). Также, проверь идущие за бутсектором сектора со 2-7 и сравни их с аналогичными на рабочем томе. Эти сектора идентичны на всех томах NTFS, независимо от их размера. Перегружайся и смотри, потом сюда.

KLASS Да, вроде разницу в нескольких знаках заметил между первым и последним секторами тома. Исправил. Сектора 2-7 пока не сравнивал. И что дальше?..

BESA

Цитата:

И что дальше?..

Замени все сектора и перегружайся, если снова будут не видны файлы, значит у тя разрушений больше, чем в бутовых секторах. Тут уже только то, что ты сделал, т.е. спасать данные программами из шапки и переформатировать диск.

KLASS Сектора 2--7 идентичны. boot-сектора в копии и на 1-м сектора идентичны. Partition Table Doctor 3.0 говорит, что check таблицы без ошибок. Данных до сих пор не вижу. Я сфотографировал свои манипуляции и конфигурацию диска. Может, выложить куда-нибудь фотки? Кроме того, Думаю проверить диск ptedit -- что-то подозрения закрались на счет конфигурации партиций. Кстати, после игр с ptedit и проверки в Partition Magic на месте, где в проге указывается метки томов, появились вопросительные знаки. Я уж было решил, что доигрался и вернул диск к жизни. Ан, нет...

Данных в принципе, не жалко -- все важное я уже слил. Жалко времени на установку системs... Кстати, как у конкретного винта будет с надежностью в дальнейшем?

KLASS, и спасибо большое вам за помощь.

Не подскажите, что это может значить: на диске изначально значение Head составляло 255. Теперь -- 240.

Еще вопросик.
После восстановыления инфы, вся музыка и видео перестали читаться... пишет что не хватает кодека (но проблема не в этом 100%).
Использовал EasyRecovery и GetDataBack
ЧТо может быть такое?

BESA
Проверь бутсектор "невидимого" тома на предмет соответствия. Описание бутсектора NTFS смотри тута http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prkd_tro_ilxl.asp

Цитата:

Кстати, как у конкретного винта будет с надежностью в дальнейшем?

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

Цитата:

что это может значить: на диске изначально значение Head составляло 255. Теперь -- 240.

Если ты про таблицу разделов, то в Acronis DiskEditor у меня стоит 254, т.е. с 0 по 254 = 255 головок, но система эти данные в таблице разделов не юзает.

Ссылку поправил, сначала не ту дал.

Aruss

Цитата:

После восстановыления инфы, вся музыка и видео перестали читаться...

Значит, не восстановились они. Просто скопировались какие-то фрагменты под теми именами, но не относящиеся к тем файлам.

LeoT, Понятно. А есть какие-нибудь надежды реанимировать?

Aruss Если на оригинал ничего не писали (и не запускали никакие исправления файловой системы), то надежды есть. Надо смотреть, что там не так (в бутах и т.п.). Автоматические рекаверилки берут за основу для анализа файловой системы те параметры, которые есть на диске. Если эти цифры неправильные, то и результат будет неправильный. Искусственный интеллект пока не всегда может заменить человеческий...
Что именно произошло в данном случае, сказать сложно, не зная подробностей.

Уважаемые ГУРУ, убил винт по глупости:

Переносил систему с одного винта на другой, соответстевнно делал все через Backup-Restore, бэкап на ДВД закатал, после чего развернул на новом диске. Далее мне было нужно сделать раздел активным - черт меня дернул и я промазал, вместо этого очень быстро надавил на Enter на строке "Clear MBR ...<что-то там еще> " - в секунду исчезли все разделы, диск стал unformat...
На диске перед "Clear MBR ...<что-то там еще>" были 3 раздела

1 - 10001 МБ - сама система NTFS
2 - 39997 МБ - пустой раздел FAT32
3 - все оставшееся примерно 102468 МБ - фото, видео, видеоролики, в общей сложности порядка 2500 файлов примерно 60 Гб NTFS

Все разделы как основные...
На саму систему пох, ее можно развернуть в любой момент, слить все, что есть на 3 разделе впринципе возможно, но хотелось бы, что бы диск просто вернулся в состояние до "Clear MBR ... <что-то там еще>"


В данное время винт не размечен, в состоянии сразу после "Clear MBR ...<что-то там еще>" - подозреваю, что затерлась Таблица разделов, винт не форматировался, на него ничего не записывалось...