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

xekanet

Цитата:

на каком этапе считается CRC (которая отвечает за данные) которая идёт в сектор?

При записи/чтении - ни на каком. Уже очень давно вместо CRC используется ECC. Это позволяет не только определить наличие ошибки, но и, очень часто, скорректировать ее (есть определенные ошибки, на которые действует ECC).
ECC считается перед записью инфы в сектор, насколько знаю, электроникой винта. Т.е. это хардверная реализация. Она работает в реальном времени. Также в реальном времени определяется/корректируется ошибка при чтении. На самом деле этих ошибок возникает много, просто они корректируются (как с повторным перечитыванием на следующем обороте, так и без него).

Данные, передаваемые по интерфейсу, защищаются CRC. Да, на этапе передачи используется CRC, но она далеко не всегда отлавливает ошибку. Эта CRC не идет в сектор, она только для интерфейса. Ошибок интерфейса зачастую происходит очень много (глючный шлейф и т.д.), и в некоторых случаях не удается зафиксировать их. Тогда и происходит искажение данных: повторная передача по интерфейсу не выполняется, и глючная инфа записывается винтом. Разумеется, ECC рассчитывается уже в винте для искаженной инфы...
Этим объясняется идентичность глюка в структурах ФС при повторных чтениях: большинство интерфейсных ошибок устраняется повторной передачей при "срабатывании" интерфейсной CRC, и при чтении не так уж этои глюки заметны, но вот когда при записи, хотя бы один раз структура испортилась, это уже видно, т.к. зафиксировано на винте.

Нужно отметить, что, в отличие от ошибок чтения, которых происходит много при нормальной работе винта (они убираются ECC, см. что-то типа Hardware ECC recovered RAW на Сигейте), ошибок интерфейса при исправном железе нет вообще.

Antech
я вас понял, просто представлял сектор так:

где CRC нужна для целосности а ECC для корекции, а как тогда он выглядит сейчас?!

Про ECC понял, по крайней мере по тем темам которые вы дали, читаю. Отлично описано.

Привет всем!
Antech
У меня проблема, прошу помощи!
Делал утилитой HDClone образ партиции диска №1 (ST3250823AS), на партицию диска №2 (WD5000AAKS). Все было вроде нормально, образ создался, но в конце прога что
то спросила, и я не стал переводить, а жмякнул, Дальше! В конечном итоге на раздел диска №2, размером в 280 Gb, был развернут образ той партиции, которую я пытался сохранить! Что меня привело к величайшему недоумению и огорчению. Видимо я что то недопонял, или глюканула прога, не совсем легальная! Прошу вас, помогите восстановить партицию с утеряными данными. Что мне необходимо предоставить, напишите, плиз! Редактор DMDE у меня есть, v. 2.4.6.
Заранее благодарен!

xekanet
О, ECC и CRC могут быть в секторе одновременно? Не знал о таком.


Цитата:

как тогда он выглядит сейчас?

Это даже специалисты не всегда точно знают. Форматы секторов у разных вендоров наверняка различны. В принципе, для софтового DR (как в подобных темах) это роли не играет, но если Вы хотите заняться физическим, то может иметь значение. Но тогда Вам и карты в руки, это уже выше моих познаний.

ru1956
Даже не знаю что предложить. Тут где-то был специалист по применению HDClone, а я не знаю что за образ она делает. Но есть подозрение, что образ посекторный, и тогда врядли что-то можно восстановить. Вы не помните, какой тип образа делали/развертывали? Посекторный? И еще, пожалуйста, сообщите размеры исходного раздела (образ которого создавался) и того раздела, в который скопировали (каким он был "до того как").

Antech
Создавался образ партиции С: (WinXP2), диска №1, размером в 16 Gb.
Но готовый образ занимает место в 8 с лишним Gb, т.к включена опция Fast.
Прога делает посекторный образ партиции, может с пустым местом, а может и без.
Несколько раз делал, все было Ок, а тут что то случилось, не думаю, что это я так тупанул.

Я смотрел по DMDE диск №2 , так предыдущее название этой партиции J: (Reserv) он видит.
После раскатки образа она стала называться С: (WinXP2), так же как и деланый мной образ.
Диск №2 содержит три первичных раздела, речь идет о втором.
1 - 16 Gb
2 - 273 Gb
3 - 176 Gb
Может какие то сектора вам скинуть, для информации, может станет более понятно?
Пока спасибо, что откликнулись!

ru1956
ОК, понятно. DMDE можеть видеть MFT Mirror, что с MFT - неизвестно.
Попробуйте Поиск MFT в DMDE, в качестве области можно задать пространство второго раздела. Посмотрите, не нешлось ли исходное содержимое второго раздела (которое нужно восстановить) в одном из найденных разделов. Если нет, значит, вероятно, только по сигнатурам искать. Это умеют разные проги: RecoverMyFiles, R-Studio... Но найденные таким образом файлы будут без имен и структуры каталогов, и с глюками вместо фрагментированных.

Antech

Цитата:

Попробуйте Поиск MFT в DMDE

Что то я не нашел в DMDE такой функции? (Поиск FAT, Поиск NTFS).

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

ru1956
Сорри, это я опечатался, фича называется "Поиск NTFS".


Цитата:

моим данным кранты, т.к. было поверх посекторное разворачивание образа?

Но ведь делался образ раздела 16 ГиБ в раздел 273 ГиБ? Как минимум, что-то должно найтись по заголовкам, если что-то было за пределами первых 16 ГиБ. Кроме того, опция "Fast" наверняка подразумевает не посекторный образ, а либо пофайловый, либо "полу-посекторный", т.е. без пустого пространства. В обоих случаях первые 16 гиг будут покоцаны, но не затерты полностью. Это тоже несколько повышает шансы хотя бы частично спасти инфу.
Поэтому, ИМХО, есть смысл попробовать "Поиск NTFS". Если это не даст результатов (MFT затерлась при копировании образа), то можно попробовать что-то найти в R-Studio, RecoverMyFiles, File Scavenger и т.п. (DMDE только по ФС умеет, если за год к ней не прикрутили новый функционал для сигнатурного поиска).


Цитата:

А что по этому поводу может сказать Ваш коллега, который с HDClone хорошо очень знаком?

Я не был в теме больше года, только недавно начал регулярно проверять ее. Поэтому я и ника его не помню. AFAIR, он не занимался серьезными раскопками логики, но зато тестил разные рекаверилки и т.п. проги. К сожалению, его деятельность здесь была воспринята как реклама определенных прог, поэтому возможно, что он уже в теме не появится, хотя, кто знает...

Antech
ну по всем статьям давности 2005 -2009 годов прослеживается crc вместе с ecc поэтому и спросил. Как сейчас хз. Впринципе да, это не имеет значения, просто ради понимания принципов функционирования. Буду дальше читать ntfs, это практичние, вы правы.

xekanet
А эта CRC для чего? Для поля ECC, или для DATA, или для нескольких полей?

Цитата:

К сожалению, его деятельность здесь была воспринята как реклама определенных прог,

Что то я не припомню здесь такового. Может с хоботом попутали (Alex_Raz)?

Уважаемые, помогите плз.
Был файл с русским именем (документ MSWord), почил безвременно от моих кривых рук (случайно удалил).
OnTrack EasyRecovery не нашёл его ни в одном из режимов (даже raw).
Что порекомендуете? С WinHex-ом не дружу, мне бы какой-то попроще вариант...

Helmsman

Цитата:

мне бы какой-то попроще вариант...

Свежеудалённые (мимо корзины) файлы почти всегда и сразу находит Recuva (особенно если на диск ничего не писалось).
Быстрая, портабельная и бесплатная, кириллицу видит. Есть во многих сборках Тотала (экстрим-пак от Сэма и пр.)
Для ещё большей простоты и скорости в мастере при старте можно задать каталог поиска и тип файла.

"Случайно" удалённые файлы может найти чуть ли не каждая рековерилка.
И если такое не произошло, то напрашивается вывод что файл находился на разделе, где идёт интенсивная запись (системный) и что даные файла (в MFT и на самом диске) переписаны чем то другим.
И если это ещё не случилось то самое 0-вое действие - исключить новые записи на раздел. И ишь потом пробовать использовать какое либо ПО.
PS. Новый формат офисных документов по сути является архивом, поэтому есть проги, которые в режиме поиска по сигнатурам относят их к категории архивов. Так что нелишним будет посмотреть таковые и по структуре понять что это на самом деле.

9285

Цитата:

Может с хоботом попутали (Alex_Raz)?

Может быть, много времени прошло...

Helmsman
Остается только согласиться с 9285. Неинтенсивная запись на раздел, даже несистемный, может убить файловую запись за несколько минут.

Antech
ну она как я понимаю для data чтоб при чтении свериться и если два (старый и новый CRC не совпали) - включить механизм ECC.

xekanet
Как это старый и новый?
ECC позволяет и проверять правильность чтения, и исправлять. Поэтому я не понимаю, зачем в добавление к ECC нужна CRC...
Хотя CRC может быть разной разрядности и разных параметров, в любом случае она довольно слабо защищает. Например, при передаче по шлейфу используется CRC, но когда она не срабатывает, вылезают ошибки типа смещений или глючно опущенных/поднятых битов. Это обычное дело в DR-темах. Если бы винты так работали, они были бы совершенно ненадежны, т.е. постоянно выдавали бы искаженную инфу, потому что ECC приходится применять ну очень часто (посмотрите Hardware ECC recovered RAW на Сигейтах). Насколько я знаю, подобной фигни не происходит именно за счет очень хорошей защиты через ECC: даже когда не сработает CRC (не заметит ошибку), ECC сработает. В связи с этим выглядит странным применение CRC вместе с ECC. Может, это CRC для поля ECC, как дополнительная защита?

помогите кто-нибудь мне с моей проблемой

Antech
Тогда логично почему он идет следующим в порядке чтения, да? а не перед ECC. Но получается ECC должно отрабатывать каждый раз, чтоб как минимум проверить целостность прочитанных перед этим данных? или механизм запуска всё-таки есть?

kosfess
Программы для восстановления информации находят хоть какие-то файлы в режиме RAW-поиска???
Плюс в той теме ответили:
Цитата:

чёт у тебя в дампах одни 00

Цитата:

чёт у тебя в дампах одни 00

Так это только бутсектор. Потому и ФС RAW. С нее посекторку в файл, а потом препарировать
данные из файпа (если они еще есть). А-то можно флешку окончательно добить экспериментами.

Цитата:

Так это только бутсектор.

Два бутсектора.
Сейчас у меня нет под руками флэшки чтобы провести эксперимент, поэтому не могу представить что бы показал DMDE в случае если бутсектор раздела в LBA0 заполнен 00-ми, но думается что другие бы элементы может и показал. А там чисто, даже нет свободного места.

kosfess
Что-то там нули везде... Пожалуйста, покажите дамп 1000 начальных секторов флешки (как физического диска) и, если не затруднит, результат "Поиск FAT" в DMDE, область - вся флешка.

kosfess
Похоже действительно если что и найдётся, то только RAW поиском. От файловой системы по видимому там ничего не осталось. Я бы попробовал WinHex. Tools>>Disk Tools>> File Recovery By Type. Ну и выбрать тот тип файлов, которые нужно восстановить. И папку куда пойдет восстановление (Output Folder) надо создать заранее, естественно на другом носителе (а то один участник тут умудрился "восстановить" файлы на тот же носитель откуда они были удалены).

xekanet

Цитата:

почему он идет следующим в порядке чтения, да? а не перед ECC

Ну, если это CRC для ECC, то вполне логично...

Alex_Green
А может, для сигнатурного лучше что-то типа RecoverMyFiles или R-Studio? В старых версиях WinHex сигнатурный поиск был не ахти...

Antech

Цитата:

А может, для сигнатурного лучше что-то типа RecoverMyFiles или R-Studio? В старых версиях WinHex сигнатурный поиск был не ахти...

Может быть. R-Studio вроде существует довольно много версий и некоторые из них тоже восстанавливают не ахти. Recover My Files не пробовал, поэтому ничего не могу сказать. Насчёт WinHex могу только сказать что в версии 16.3 мне неоднократно доводилось восстанавливать такие форматы файлов как Jpeg, Tiff, Gif, Avi, Mov, DocX. Вроде ничего плохого сказать не могу.

Alex_Green
А там появилось автоопределение размера файла? Я пробовал в какой-то старой версии, размер задавался фиксированный.

Antech
Сейчас специально на скорую руку записал на флэшку несколько Jpeg, Tiff и DocX файлов. Затем удалил всю эту папку. После этого в записях корневого каталога нашёл начальный кластер этой директории. Занулил там все записи об этих файлах. Попробовал в даной версии (16.3) WinHex восстановить по очереди эти файлы. Восстанавливаются с исходным размером. Честно говоря, я даже на такие нюансы (как размер восстановленных файлов) и внимания то не обращал. Хотя это наверное естественно, поскольку я не профи по восстановлению. Так, иногда занимаюсь этим в рамках работы в сервис центре по обслуживанию компьютерной техники.

Alex_Green
Спасибо. Значит улучшили алгоритм. Раньше надо было задавать размер, а теперь, вероятно, берет до следующей сигнатуры, а может и что-то из-заголовков достает.

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

А вот за инфу

Цитата:

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

спасибо. В следующий раз буду умнее, попробую ещё и по сигнатурам архивов шуршать.