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

Приветствую всех в этот не добрый для меня час.
За помощью пришёл на этот форум.
Вельзевулово отродье к коему я на своё горе подключил системный 3х терабайтный диск, решило что из 3х терабайт мне вполне и 802 ГБ хватит, после чего обьём жесткого диска сократился до этого размера.
Я, не совсем согласный с данной точкой зрения, скачал Волшебную программу (HDD Capacity Restore Tool), после чего попытался восстановить исходный размер.
Собственно, что хотел, то получил. Размер восстановлен. Вот только то, что попало в 2,2 ТБ забвения, осталось там. И на выходе у меня раздел на весь обьём диска, с данными по факту на 802 гига.
Что теперь делать, не представляю, MFT буд то в клочья разорвало.
Дамп первых 200 секторов
Скрин разделов:

то, что он тут накопал (кроме FILES, который на самом деле худее где то на 500 ГБ должен быть), вообще какие то разделы из далёкого небытия, и мне нафиг не сдались
Скан NTFS:


И ещё интересную вещь нашёл, в R-Studio когда фалы копаешь, он их находит и восстанавливает. А вот путь, по которому (как он думает) они находятся, вообще случайный. То есть часто путь к фильму ведёт в дебри каталога какой нибудь программы, и там естественно по факту его нет.

arttdat
Ты уверен что именно эта материнка подрезала диск? Я пока что знаю про гигабайтовские, и связано это с их спецификой. И подрезала ли? Может просто отображался как 7хх гигов?
Если было реально только подрезание размера, то после восстановления исходного размера данные должны быть доступны, но... если в период кастрации не было исправлений чекдиском - подозреваю что последнее было.

Сохранил лог поиска NTFS, Если да - выложи его, т.к. картинка даёт информацию, но не очень большую.
По результатам поиска открывал том, начинающийся в секторе 2048 - что в нём?
И ещё бы взглянуть на дамп секторов 2048+20 последющих.

temp9285
Не уверен, но ничего другого к этому диску не подключалось, кроме материники на которой всё работало хорошо. Насчёт подрезала ли, не знаю, сама материнка при буте говорила, мол 802 гига диск.
В период исправления исправления чекдиском не было. Каюсь, после было, буквально час назад, но вроде ничего фатального, скрин месева из MFT и разделов делался до него.
Лог и дамп
В том томе мой второй раздел. Был системник и второй с файлами. Так вот это тот который с файлами.
Вроде всё так же как и было. А вот системный раздел канул в бездну.

arttdat
То есть, в БИОСе он идентифицировался как 802 гиговый?
Судя по всему, твой системный начинается в секторе 5735215104 (в логе поиска он NTFS4) - да его и на экране Разделы видно.
И он перекрывается нынешним разделом на весь обьём диска - откуда такой взялся?

С дампом "просчитался" - забыл что есть те, кто пользуется акронисом.
Можно взглянуть на 2072+32, 690184+100 а заодно и 5741506560+100 ?

Насколько понимаю, сейчас винт подключён к другой системе. Если хочется восстановить что то с системного (да и вообще) - лучше сделать GPT off (не забыть применить изменения и перезрузить систему).

Цитата:

То есть, в БИОСе он идентифицировался как 802 гиговый?

именно

Цитата:

в секторе 5735215104

то есть это где то 64 гига получается? мало, он гораздо больше был.

Цитата:

перекрывается нынешним разделом на весь обьём диска

вот я и думал на этот capacity restore, что он мне на весь обьём растянул раздел с файлами

Цитата:

те, кто пользуется акронисом

на меня намекаете? я пользовался им весьма давно и перешёл на Paragon Partition Manager

Цитата:

2072+32, 690184+100, 5741506560+100

вот

Цитата:

GPT off

сделано

Может кто подскажет
ноутбучный ST9320325AS были бэды, отрезаны. Дал человеку попользоваться, в один день ноут выдал синий экран и больше не загрузился. Victoria разделы видит, в юсб кармане зависает. Тест в любом режиме приводит через несколько секунд к TTTTTTTTTTT и зависанию. Досовские менеджеры разделов не увидели. Как можно достать инфу?

ss661
Вполне может быть дело закончится заменой головок, чтобы спасти инфу.
Можно попробовать заблокировать ошибки, чтобы не вис.
в теме по сигетам были команды T>Fxxxx
Но только после проверки записи.

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

arttdat

Цитата:

то есть это где то 64 гига получается? мало, он гораздо больше был.

Насколько больше? 118гигов? Есть и такой раздел, вот только число записей MFT у него маловато для системного. Впрочем. ничто не мешает открыть и посмотреть все возможные кандидаты.


Цитата:

вот я и думал на этот capacity restore, что он мне на весь обьём растянул раздел с файлами

Она не занимается логическими изменениями.


Цитата:

на меня намекаете?

Нет, на тех, у кого старая версия NTFS и начало MFT и зеркала такие какие в дампе.
И это характерно для акрониса.

PS. Я конечно же верю про то, что разделы были другие, но факты (дампы) свидетельствуют о различных изменениях - в том числе о том, что когда то раздел был примерно 2,4тб.

ss661
Желательно подключить без карманов. И подозреваю что сначала надо разобраться с физическими проблемами.

Цитата:

Насколько больше?

точно не помню, но больше 400

Цитата:

Впрочем. ничто не мешает открыть и посмотреть все возможные кандидаты.

поясните?

Цитата:

Она не занимается логическими изменениями.

тогда у меня идей нет

Цитата:

что когда то раздел был

возможно, таких подробностей не помню

arttdat
На экране Разделы виден том (жёлтенький) с началом в секторе 5504552960.
Вот его и открой.
Если его сейчас не будет видно в списке разделов, то можно перейти в этот сектор, сделать вид "Загрузочный сектор", затем нажать пару раз Enter.

Цитата:

открой

вообще левое что то

arttdat
Если ты не можешь определить что это за левое, то как то напрашивается мысль что ты малознаком с этим диском. И в свете этого, в утверждение о 400 гиговом системном разделе, как то не верится, особенно в ракурсе имеющихся данных. (*)
В принципе, есть пара фрагментов MFT - кандидатов (**) на такой (с началом в секторе 4779030948). Но один из них зеркало, а основной всего 16 записей. К тому же размер кластера 512кб. Ладно, я могу поверить что это заголовок отформатированного акронисом раздела, но должно же быть продолжение. Да и сама MFT системного раздела имеет тысячи записей - и то, если это ХР; для последующих версий число уже несколько десятков тысяч. И такие есть, но в уже обозначенных началах.
Можешь сам проанализировать результат поиска - в меню есть пункт "Все фрагменты MFT". Вот и попробуй найти подходящую цепочку.
(*) Есть один вариант, который относительно укладывается в имеющиеся данные - система стояла на виртуальном диске (vhd).
(**) Эти фрагменты в секторах 4779036110+12, 4779033006+32

PS. Можно попробовать найти 6-ю запись MFT, в которой размер битовой карты тома будет соответствовать ожидаемому.
Затем идентифицировать к чему относится эта запись.

Доброго.
Нарисовалась проблема. На серваке имеют место несколько дисков WD объемом от 4-х до 6_ти ТБ. При подключении другого сервака непонятным образом был потерт (забит 0_ми) нулевой сектор дисков - инфа не читается... Через Акронис и Сонату видно, что инфа цела, но восстановить 0_ой сектор не получается. Может кто из опытных подскажет способы инструменты, которыми можно восстановить 0_е сектора, чтобы получить доступ к инфе.
Душевно, с наилучшими.

moroka33
Сразу на всех слетели?
И что значит при подключении другого сервака? По сети (локальной)
Или всё таки при подключении винтов к другому серваку? Так может раньше был рэйд (вариантов которых куча, в том числе и софтовые)?
Если без рэйда и просто винты, то как бы напрашивается GPT, у которой в 0-вом прописана "заглушка" - Protective MBR, которую можно соорудить вручную остальное берётся из других секторов.

temp9285

Цитата:

Сразу на всех слетели?

Да, однообразно, грешим на глюк контроллера, но...(((

Цитата:

что значит при подключении другого сервака

правильно

Цитата:

при подключении винтов к другому серваку

Цитата:

может раньше был рэйд

Рэйд_а не было, при переносе сервак запросил как винты учитывать, была поставлена метка на варианте: как рейд 0_го уровня... Похоже поняли, что-то неправильно, но...
Варианты откатитьне просматриваются?

moroka33
Всё таки уточню.
Были просто винты, которые перенесли в другой сервак и там их инициализировали как 0-вой рэйд?
Если да, то всё зависит от того, что сделал контроллер с винтами - одно дело если только инициализировал, но сами данные не затронул; совсем другое если он и "поляну" переполосовал.

Кхм. Ты уверен что хочешь сам решить эту проблему? Если уверен в своём желании и не будет очень больно в случае неудачи то тогда надо выключить сервак (*), запомнить какой винт куда подключён, снять все вставленные, подключить для начала какой то один к обычному компу (поддерживающему работу с такими винтами), ничего не инициализировать, не разрешать делать проверку диска и т.п. - запустить DMDE, выбрать этот физический диск и сделать скриншот экрана разделы - показать здесь.
Но лучше всё таки пригласить хотя бы сисадмина.

temp9285

Цитата:

Были просто винты, которые перенесли в другой сервак и там их инициализировали как 0-вой рэйд

Да.

Цитата:

инициализировал, но сами данные не затронул

moroka33

Цитата:

Через Акронис и Сонату видно, что инфа цела

Цитата:

уверен что хочешь сам решить эту проблему?

Скажем так, хотелось бы рассмотреть варианты, может есть простое и внятное решение.) Вопрос подобраться к 0_му сектору напрямую... Восстановить за большие деньги есть к кому обратиться....)

Цитата:

запустить DMDE, выбрать этот физический диск и сделать скриншот экрана

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

Привет всем. А вот и я - сам виновник "торжества".
Благодарю moroka33 за точность в изложении хода событий. От себя добавлю, что винты стояли в системе FreeBSD, по одному UFS разделу на каждом. Перенос произошел в сервер HP с райд-контроллером.

moroka33

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

Что касается дисков большого объёма - приятели из фирмы-диллера WD рассказали что по их наблюдениям у всех ОС семейства Windows есть проблема с дисками большими 5 Тб:

"...4Тб и меньше ось видит и работает с ними нормально, а 5 - 6 Тб приходится бить на разделы по 3 Тб - целиком даже десятка с ними не работает. Мелкомягкие берут отчёты, обещают помочь, но пока решения не придумали...".

Цитата:

есть к кому

Если "есть к кому" - ваш знакомый, но за восстановление он сдерёт "большие деньги"... это не ваш знакомый и лучше к нему не обращаться
А вот это важно

Цитата:

Но лучше всё таки пригласить хотя бы сисадмина

Если это вы и есть - тогда ой

Цитата:

Были просто винты, которые перенесли в другой сервак и там их инициализировали как 0-вой рэйд
Да.

Весьма наплевательски относитесь к дискам с важной инфой

onenet

UFS? Тут со слайсом придётся возится - т.к. фирмваре контроллера потёрла первые блоки и если не известна геометрия разметки работы будет много. Давайте танцевать от известного. Контроллер при подключении нового диска выполнил инициализацию потерев нулями часть поверхности (возможно и всю), но следы остаточной намагниченности при однократной перезаписи не уничтожаются и специальным оборудование с соответствующим ПО данные восстановить можно, хотя гарантировать 100% удачность операции не стану. Давайте для уверенности возьмём вероятность успеха равную 0,2.

Что нужно сделать это просмотреть конфиги той машины где стояли диски sd?? и выписать на бумагу всё что касается геометрии их слайсов, а там по шаблону блока UFS можно смоделировать служебные записи. Далее убедившись что ошибок в реконструкции нет создаём на другой машине бинарный набор длинной равной длине повреждённого участка, заполняем его реконструированными данными, объединяем с уцелевшей частью слайса и убедившись в корректности восстановления записываем данные на рабочие накопители.

Другой методики нет, и понятно что каждое действие надо для себя документировать и постоянно бэкапить восстанавливаемые HDD чтобы в случае ошибки откатить работу на последнюю безошибочную операцию. Если этого не делать, то вероятность полной утраты данных будет стремиться к 100% т.к. после нескольких операций перезаписи восстановить состояние магнитного слоя на момент аварии будет невозможно.

onenet

Цитата:

винты стояли в системе FreeBSD, по одному UFS разделу на каждом

Здесь я пас.
Ну разве что посоветую использовать ПО знакомое с данной ФС или поиск по сигатурам (щаз окажется что и файлы не очень типичные ).
Victor_VG

Цитата:

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

Это и на более меньших винтах уже давно невозможно - впрочем, если сообщить в ФБР, что там есть что либо относящееся к террору в отношении СШП, то что то и восстановят (на атомарном уровне).

Ну вообще-то это были диски, забитые медиафайлами (в медиасервере). Суммарно 25 ТБ инфы. HEX-редактор показывает забитую нулями начальную область диска, не могу по памяти сказать сколько секторов, предположительно первые 8192 кб (соответствует GPT). Но далее вся инфа на месте.
R-Studio просканил поверхность и отчитался о найденных файлах, но проблема в том, что структура файлов и их имена он не видит - просто список из нескольких тысяч файлов.
Из базы данных медиасервера я могу точно выдрать список файлов и структуру каталогов на каждом диске. Вопрос в том, как эту инфу объединить в одно целое.

Цитата:

но следы остаточной намагниченности при однократной перезаписи не уничтожаются и специальным оборудование с соответствующим ПО данные восстановить можно, хотя гарантировать 100% удачность операции не стану. Давайте для уверенности возьмём вероятность успеха равную 0,2.

Перестаньте повторять теории 30-летней давности.
С современных дисков нереально восстановить информацию после однократной перезаписи.
даже если допустить что один бит можно восстановить с вероятностью 99%.
Байт - с вероятностью уже порядка 60%
512 байт с вероятностью уже менее 1%.
Это при условии что головки будут лететь иделально ровно, а они всегда петляют. Физически не могут летать по одной и той же траектории, всегда с отклонением +/- 5-10% от центра трека данных. Поэтому определить к чему относится восстановленный бит, невозможно.
Ширина трека порядка 10-15 нанометров, один домен порядка 2-3 нанометров, с краю останется 1-2 домена.
Нет таких головок, которые смогут читать 1-2 домена, которые останутся на краю трека. На это место невозможно спозицианироваться по существующей серво разметке
И любой восстановленный бит может быть, ошметок от текущей записи, от любой предыдущей или от соседнего трека.

Всякие магнито-резонасные методы чтения безумно медленные, требуют вакуума.
С позиционироваться в нужное место, с точностью 1-2 нанометра ни какими разумными методами нельзя.
Маленький образец, заранее подготовленный и хорошо закрепленный в условиях отсутствия малейших вибраций, исследовать еще можно.
А целый блин - не реально.
Не говоря о том что методы кодирования информации различный у всех производителей, даже на одной модели их десятки и тысячи раз поменялся за 30 лет.
ФБР и прочие гос конторы, точно также обращаются в известные DR фирмы, получивщих на такие работы соответствующий допуск.
Держать отдельную службу для DR совершенно неоправданно дорого даже для мин. обороны.
Причем многие такие конторы, частенько предпочитают обращаться не в больше DR конторы, а к знакомым частникам с хорошей репутацией. Дешевле, и инфу если и увидит, то только один человек, а не группа специалистов и менеджеров.

DR это совершенно отдельная тема.
Сами производители дисков не умеют восстанавливать со своих дисков информацию.
Заключают договора с известными DR фирмами на различных условиях.

onenet
GPT поменьше занимает места.
Я не в курсе как устроена UFS, но если сами данные видно то можно предположить что R-studio не знакома с этой файловой системой и ты получил результат сигнатурного поиска. Одно радует, что целы и может чем другим найдётся в более удобоваримом виде - посмотри http://rlab.ru/tools/ufs_explorer.html

Victor_VG

Цитата:

у всех ОС семейства Windows есть проблема с дисками большими 5 Тб:

onenet

Цитата:

винты стояли в системе FreeBSD

Все было путем, работали нормально...
igor_me

Цитата:

А вот это важно

Это контора, которая этим занимается.)

Цитата:

Весьма наплевательски относитесь к дискам с важной инфой

По запаре всякое бывает...)
Victor_VG

Цитата:

Другой методики нет

Внятно и даже мне понятно.)
tomset

Цитата:

Сами производители дисков не умеют восстанавливать со своих дисков информацию.

Умеете, вы батенька, обнадежить...)
temp9285

Цитата:

посмотри http://rlab.ru/tools/ufs_explorer.html

Душевно.

Добавлено:
temp9285

Цитата:

Что душевно?

Есть такая старинная фраза - благодарю дущевно...
В данном случае, за конкретный линк на профильный софт...)
С наилучшими.

moroka33
Я не понимаю этого новояза. Что душевно?
Цена или возможность проверить есть ли остатки файловой системы и т.п.?

Судя по обстоятельной инфе tomset дела мои плохи... Хотя по большому счету инфа не особо критична.
Винты сдал на восстановление специализированной конторе. Сообщили что восстановить смогут, но часть инфы будет битой. Через неделю сообщу результаты.

Хм, зачем было

Цитата:

сдал на восстановление специализированной конторе

если

Цитата:

Но далее вся инфа на месте

Ну и скинули бы инфу. Ну хозяин-барин...

кривыми руками с помощью Акрониса при попытке изменения размера с последующим переносом была убита файловая система диска Д. вместо Д теперь RAW раздел. диск С живой система грузится с него.

вопрос:
диск Д был заполнен на 1/3 т.е. из 400 гб на нем было занято порядка 150гб.
Место для переноса восстановленных файлов нет.
Если я от конца раздела RAW откущу например 150 Гб и создам на этом место новый раздел,
не повлияет ли это на "данные" которые по идее остались в разрушенном разделе ?