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

9285

Цитата:

Ты определись с тем, что затёрто.

Если удалялся какалог то и файлы в каталоге тоже были удалены. Это значит, что кластеры в отрезках, соответствующие этим файлам стали незанятыми в $Bitmap этим кластерам соответствуют 0, а не 1. Система имеет полное право в них писать... А каталоги видимо остались...

Я думаю, что так...

limbast
Судя по логу, повреждены записи 0-2. Поэтом, если хочешь восстановить раздел in-place (и понмаешь все возможные риски) нужен дамп секторов 6293504+10. Плюс, можно дёрнуть удачу за хвост - сектора 205804936+8.
Возможно ошибка логическая, но они нередко являются следствием физических - поэтому нужен SMART.

Tau_0
Прочти осмыслено цитату из твоего ответа.

9285

Цитата:

Tau_0 Прочти осмыслено цитату из твоего ответа.

В двух словах, небольшой каталог будет полностью сохранён резидентно в файловой записи (атрибут Root невелик) . Поэтому он не пострадает в том смысле, что его можно восстановить.
А вот файлы имеют нерезидендную часть, поэтому система их может затереть.

ЗЫ Практической пользы для lastborn56 от этого никакого…

Tau_0
Что ты юлишь как вошь на гребешке?
Ты написал ложь. Всё остальное попытка вылезти из лужи.

9285

Цитата:

Ты написал ложь.

Укажи в чём она состоит...

Tau_0

Цитата:

Похоже на то, что в MFt файловые записи осталились, но их run-list (сами данные) давно другой информацией перекрыты...

9285
А--- аа --- ааа...
Просто слишком в спешке конспективно написано, хотя не педанту ясно... Неужто трудно понять, что run-list (фактически списки указателей) ханится в File Record, а сами отрезки нерезидентно во внеших кластерах. Они то и освобождаютя, поэтому и могут перекрыться...

Зы базовые определения я знаю (если не все, то их просто найду...), но вот с практическим использованием похуже.

Цитата:

Неужто трудно понять, что run-list (фактически списки указателей) ханится в File Record, а сами отрезки нерезидентно во внеших кластерах.

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

Цитата:

Судя по логу, повреждены записи 0-2. Поэтом, если хочешь восстановить раздел in-place (и понмаешь все возможные риски) нужен дамп секторов 6293504+10. Плюс, можно дёрнуть удачу за хвост - сектора 205804936+8.
Возможно ошибка логическая, но они нередко являются следствием физических - поэтому нужен SMART.

Вот сектора, что вы просили Ссылка
На счет смарта, не знаю что с винтом, но ни одна программа не считывает ни SMART, ни firmware, ни серийник! Видимо плохо совсем, однако второй раздел на указанном диске работает как обычно. И еще, может это чем то поможет, этот диск когда то подцепил муху, выдавал и смарт и все остальное после этого, но теперь не выдает. Возможно потому что он подключен через JMicron.

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

9285

Цитата:

пытается понять все премудрости логической структуры данных.

На это есть хорошие книги и статьи, где очень подробно энтузиастами Linux-Group устройство NTFS dв целом разобрано...

ЗЫ Да и я более развёрнуто у же писал ===>

Цитата:

... Указатели есть, но сами run/extent/отрезки затёрты…

Но тебя это не удовлетворило…

limbast
Пендинги, релокейты, ошибки передачи данных - в общем то есть предпосылки к сложившейся ситуации.
Можешь по результатам поиска восстановить данные с помощью DMDE на другой носитель.
Если же решишься на in-place, то можно сделать и так. Тем более что MFT нефрагментированая и любой начитавшийся книжек сможет восстановить заголовок. Это относится к Tau_0 и его крайнему спитчу.
Tau_0
Можно учиться в десяти лучших автошколах при этом не уметь в реальности водить авто, а можно и без них стать ассом.
Вот сейчас есть наглядный случай показать что ты:
- имеющий здесь бОльший стаж
- читающий много скрижалей
- вообще программист по профессии
Можешь сделать то, что может сделать "бездарь"-самоучка (причём делает уже давно и более сложные задачки). Предоставляю тебе право первого хода - делаешь патч. Только одно условие - пострадавший его пока не применяет (извини, но я боюсь последствий).
Согласен?

9285
DMDE демо восстанавливает информацию по одному файлу, а на диске более 5000 файлов.
Прошу помощи в восстановлении, как ты предлагаешь возможно когда то я и смогу восстановить, но на это уйдет гораздо больше времени чем узнающего человека. На мою проблему только ты ответил, значит ли это что ты единственный в той теме, кто может помочь?
Если тебя не затруднит, можешь ли ты исправить проблему?

PS
В 2012 году я уже обращался в эту тему и тогда мне помог Antech. Очень быстро и оперативно, не думаю что у него это заняло много времени или потому что проблема была другого рода. Где он сейчас? Его с 2013года не видно на этом форуме, и мыло уже недействительно.

limbast
Современная демо DMDE позволяет восстанавливать до 4000 файлов из одной панели (скажем так - папки).
В любом случае, так как in-place не всегда может закончиться удачно, самое важное (критичное) надо всё таки извлечь.
Насчёт твоего самостоятельного исправления это было как бы не тебе написано, и в свете предыдущих сентенций моего визави. Конечно же, я сделаю тебе патч (но попозже) и могу сразу выложить его в ЛС. чтобы визави не мог подсмотреть
Antech в своё время практически ушёл отсюда, некоторое время ещё был активен на хоботе. Потом куда то пропал. Надеюсь что ничего плохого с ним не произошло.

limbast

Цитата:

значит ли это что ты единственный в той теме, кто может помочь?

Вам - наверно да, нужен патч. А по железу тут я иногда тоже помогаю
Если гуру меня научит делать патчи - тоже могу чуток поклепать
9285

Цитата:

На хоботе не лучше.

Хм, нашли ещё место, куда не стоит ходить? Похоже на досуге у вас хобби ходить по разным местам в инете и искать такие, куда не стоит ходить другим, гы-гы

9285
Заранее спасибо, можешь конечно в ЛС, как тебе удобно.
Перед патчем как я понимаю можно сохранить область, которая будет патчиться, и при неудаче её можно будет восстановить. Ведь так?

9285
Добрый вечер.
Наконец-то я дополз до компа.


Цитата:

Для анализа ситуации я запрашивал дампы секторов 73378896+50, 346112392+8 и 346104352+8.
А что прислал ты?

Этот вопрос ставит меня в тупик, поскольку я сделал ровно то же самое, что и в первый раз, но с учётом пожелания
Цитата:

Имена файлов дампов оставляй как предлагает программа.

Сделал ещё раз. Может я что-то не понимаю и не те интервалы задаю?


Цитата:

И ещё я писал про лог Поиска NTFS. Он тоже нужен, как и результат открытия найденных томов.

На момент написания предыдущего сообщения лог ещё не был готов.
По поводу томов. Нашлось два тома. В одном 1258 соответствий, многое из того, что было в убитом разделе там видно после виртуальной реконструкции файловой системы в DMDE. Во втором томе всего 3 соответствия.

Ещё раз дампы + лог: http://rghost.ru/56557478 (9285)

Цитата:

Перед патчем как я понимаю можно сохранить область, которая будет патчиться, и при неудаче её можно будет восстановить. Ведь так?

Если речь о первых трёх записях MFT, то толку нет от сохранения мусора. Идеальный вариант - посекторка всего проблемного раздела, но требует места соизмеримо с обьёмом раздела.
На хоботе Yatagan предлагал сохранять $MFT - это существенно меньше по размерам, и несомненно мера из разряда "лучше хоть что то, чем ничего", но есть некоторые моменты, которые не позволяют это назвать гарантированным решением.

Flavius_Aetius

Цитата:

Может я что-то не понимаю и не те интервалы задаю?

Да. И лог поиска подтвердил это.
В присланных дампах аналогия того, что было раньше, а имена прошлых дампов подтверждают что это другие сектора.
Поэтому повнимательнее и почитай шапку темы http://forum.ru-board.com/topic.cgi?forum=62&topic=20390#1 - в самом конце очень наглядно показано как делать дамп.

igor_me
У меня просто хобби писать правду бестолочам и "титулованным", которые считают что приписька эксперт, а особенно MVP является индульгенцей и всё вываленное ими - истина. Да и почти три года помощи на хоботе всё было тип-топ, но стоило мне во флеймовой теме написать так сразу оказался нарушителем. Ну а потом координатор за дрот попросту не захотел признавать свою неправоту и чтать в публичке мнения о нём. И лишил права отвечать на его "земле". Я то в привате всё равно помогаю, но преимущественно приглашаю пострадавших сюда, чтобы всякий упырь не мог мешать решению проблемы. Flavius_Aetius как раз с хобота.

Добавлено:
limbast
Патч готов, смотри ЛС.

Flavius_Aetius
http://higgs.rghost.ru/56559536/image.png
На скриншоте видно два больших фрагмента.
1. Тот что соотвествует текущему началу тома и имеет - более 63тыс записей.
Посмотрел - чистая ХР, оригинал после установки в MFT имеет до 20 тыс записей.
Соотвественно есть вариант что остальные - записи прежнего раздела с началом в том же секторе.
Или ... ты ставил какую то сборку, + к ней кучу софта.
2. Тот, у которого более 200 записей. Этот фрагмент соотвествует тому, который как бы тебе нужен.
Начальная часть затёрта, но всё же 200000 записей это же немало.

9285
Прошелся Victoria. 3 сектора нечитаемы.
Скопировал патч. Запустил chkdsk. Вот лог.
Программа Chkdsk была запущена на моментальном снимке тома в режиме "только чтение".

Проверка файловой системы на K:
Тип файловой системы: NTFS.
Метка тома: DISK K.

ВНИМАНИЕ! Параметр F не указан.
CHKDSK выполняется в режиме только чтения.

Проверка файлов (этап 1 из 3)...
Слишком большой тег вхождения 0xff атрибута типа 0x80 в файле 0x0.
Тег вхождения должен быть меньше чем 0x6.

Запись атрибута (128, "") в сегменте записи файла 0
повреждена.
Тег вхождения 0x0 атрибута типа 0xb0 в файле 0x0
уже используется.
Запись атрибута (176, "") в сегменте записи файла 0
повреждена.
Обработано файловых записей: 59392. Проверка файлов завершена.
Сегмент записей в файле 15115 потерян.
Обработано больших файловых записей: 4.
Обнаружены ошибки. Продолжение работы в режиме только чтения невозможно.

Ты писал, что я могу через DMDE до 4000 файлов скопировать в папке. Не получается! Пишет об ограничении в 4000 фалов и все, только кнопка закрыть, хотя в папке всего 51 файл.

limbast
Лог посмотрю чуть позже.
Что касается 4000 - там надо чекбокс не забыть поставить в левой части (файлы в текущей панели).
ЗЫ: Что то Tau_0 куда то запропастился. Может патч тебе пишет?

9285
Так а лога то 2 строчки и все. Или я лог не правильно снимаю?

Цитата:

Так а лога то 2 строчки и все.

Дело не в количестве, а в содержимом.
Оно мне незнакомо (например про слепок). Чем это проверялось? Новоделом (8-кой)?
Насчёт 176-го там всё верно - я его обнулил, так как нет смысла искать где находился оригинал, а чекдиск создаст новый.

Что касается сбойных секторов - в идеале нужны их номера и определить что в них находится. Чтобы знать что пострадало. Хотя может там и нет ничего, и они уже занесены в BadClus, но это надо смотреть что в нём, а я запросил лишь 10 секторов - BadClus же чуть дальше.

9285
Так какие мои сейчас действия? Что мне дать тебе или сделать?
PS Chkdsk запускал на windows 7 из командной строки. Лог скопировал с журнала windows. Все что необходимо я скопировал через DMDE, спасибо - подсказал.

limbast
А в семёрке от имени админа запускал?
Если бы не сбойные сектора (неизвестно где), то я бы запустил на исправление.

Уважаемые подскажите пожалуйста как застраховаться от так называемого "заворота винта"?
Купил 4Tb и планирую его использовать как внешний eSATA. На моих машинах драйвера контролеров обновлены но боюсь может получится что подключу его к чужой машине со старыми драйверами.
Я встречал рекомендации с созданием первого логического диска который в случае заворота будет утерян но второй и остальные не должны пострадать. Так ли это и каким минимальным может быть размер этого первого логического диска.

Спасибо заранее.

P.S.
Понимаю что вопрос не о восстановлении но где как не здесь находятся практики.

gerdalf
Самый лучший способ - иметь 2 терабайтника.

Цитата:

Так ли это и каким минимальным может быть размер этого первого логического диска.

Не буду гарантировать, но насколько понимаю суть проблемы - запись происходит в адреса, мЕньшие на число "порога). То есть, если данные пишутся в область 3тб, то при завороте они запишутся в область 1ТБ.
И если изначально заполнение может идти последовательно, то (логически) пострадает начало винта. Но в процессе эксплуатации запись может сделаться и в конец винта, особенно когда винт уже будет заполнен.
Исходя из этих представлений (не утверждений) я на хоботе и предлагал именно вариант создания "зоны безопасности". И именно большой а не 100-200 гигов. Точные размеры надо считать исходя из числа секторов на винте, и числа секторов "порога", о который уже немало споткнулось. Но в твоём случае эта зона чуть меньше двух ТБ. Причём, если не боишься "дробления" винта на разделы - сделай в этой зоне несколько. Вероятнее всего, в таком случае пострадает логика одного.
В любом случае, если потом прийдётся всё таки вытаскивать данные из накрытого заворотом раздела, лучше делать своевременно дефрагментацию, чтобы восстановление по сигнатурам могло восстановить целые файлы а не первый фрагмент. Ну и можно периодически MFT сохранять - последние записи не восстановишь, но наверное что то лучше чем ничего.

PS. Кстати, вопросом механической надёжности не задавался - ведь пластин больше, конструкция сложнее и шансов поломаться тоже побольше.

Всем приятного дня. Ребята пожалуйста помогите решить проблему. Решил с помощью акрониса увеличить размер системного диска С путем объединения с диском Д( Д был пустой). Результат - система не загружается, при подключениb винчестера к другому ПК винда диск не видит, акронис видит,но говорит что он не отформатирован. Можно ли все вернуть как и было? Заранее большое спасибо.

seva238
Акронис закончил своё действие или нет?
В любом случае покажи как и где видится + скриншот экрана Разделы из DMDE.

Цитата:

Самый лучший способ - иметь 2 терабайтника.

Если сложить риски то пожалуй я смирюсь с удвоением железа и относительно небольшим увеличением цены и обменяю четыре на два по два.

Спасибо большое за помощь.

gerdalf
Мудрое решение.
Кстати, в PS. я не заметил что поставил точку а не вопрос.

Добавлено:
seva238
И ещё что хотелось бы сказать по поводу акрониса.
У него очень много "тараканов", причём они разных версий и каждый со своими "мандавошками".
И на примере твоего случая (если за факт принять что физически D следовал за C) можно продемонстрировать несколько из них.
Очень важна версия УПД (уничтожителя пользовательских данных).
Насколько помню, в 10-ке при обьединении спрашивалось что и к чему присоединялось, в 11-ой к чему и что. А может и наоборот. И здесь очень важно правильно ответить, так как в случае если выбрать в качестве тог, к чему присоединять D, то происходят глобальнейшие перетрубации данных. И сбой в не самый удачный момент этого, приводит просто к катастрофическим последствиям.
Впрочем, если даже присоединение идёт к С, то вместо банально логических действий:
- сброс остатков данных с D в указанную папку
- удаление D
- растяжка С
некоторые версии (в том числе билды) могут тоже устроить небольшой замес данных, при которых сместится начало раздела, перенесётся MFT и т.п. Что тоже может привести к плохим последствиях.

PS. Впредь не советую пользоваться подобным ПО без наличия бэкапа, а про Акронис лучше забыть вообще.
Да и (по большому счёту) самому не создавать подобные задачи. В упомянутом мной классическом размещении разделов тебе надо было просто удалить пустой D и расширить том (лучше всего средствами самой винды (если версия позволяет это сделать).

2 9285

Поскольку 4Tb у меня на руках я готов провести эксперимент или серию экспериментов с целью выяснить как же все-таки будет вести себя "заворот".

Думаю для начала просто установить старый драйвер, создать один раздел и пробовать заполнять его скриптом типа:

Код:
@echo off
for /l %%x in (1,1,1000) do (
    for /f "tokens=* delims=" %%a in ('dir d:\ /s /b') do (
        copy %%a %%a_%%x
        )
    )