Слетела таблица разделов, "структура диска повреждена, чтение невозможно"

Есть MacBook, к ниму был подключен внешний 1тб жесткий диск (2,5'', ноутбучный), через карман USB 3.0. На этому диске у меня была виртуалка (Parallels desktop) c виндой 8.1 с которой я и работал. Работал удачно месяца 4, и вот однажды выскочила ошибка виндоуса, на синем экране, точно не помню но что то вроде error reading disk. Безопасно извлекаю диск, вставляю - не возможно смаунтить "структура диска повреждена, чтение невозможно", chkdsk не работает.

Подрубаю к виндоусовскому ноутбуку.
Что было сделано - снял образ с одного раздела. MBR не отключал, надеюсь данные в сохранности еще, лол.
Пробовал testdisk - не может найти MFT, но разделы вроде все правильно отображаются во всех программах, такого же объема как и были до ошибки, только написано что забиты полностью. Другие программы так же - видят разделы но таблицу восстановить не могут, может проблема в другом, я в этом не очень разбираюсь?

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

Курил форумы дня 4, перечитал много, ничего не помогает, боюсь уже что то лишнее делать. Прошу помощи.

Миниатюры

     

0

9285,

Это не подходящие, а те что нужно.

Но что? Все равно шансов нет?

В дампах нет даже каких то обломков от начальных записей.

Чисто вопрос интереса, всего из 10 секторов которые я сдампил, можно сделать такой вывод?

Чем лучше восстанавливать? DMDE, из поиска по NTFS?

Можно еще, в двух словах, что все таки произошло с диском? Слетела таблица разделов, MFT, что то еще или что?
Кстати вспомнил, что до того как вытащить его из ноута и вставить в карман, распределял существующие и создавал новый раздел, с помощью MiniTool Partition Wizard, может причина проблемы в этом.

0

King Tubby
Посмотрит приатаченные изображения - там:
1 - нормальная запись, но только это 4-я на месте 0-вой
2 - кусок чего то типа битовой карты
3 - начало данных индексов

Четвёртое - пример (чужой) живой записи, но со смещением. Выделены характерное начало записи и имя 0-ой записи. И до дампов теплилась надежды что и у тебя нето подобное. Но увы и ах.

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

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

Миниатюры

     

 

0

Чем лучше восстанавливать? DMDE, из поиска по NTFS?

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

Я готов поискать, если это увеличит шанс на восстановление большего числа файлов. Как искать-то?

И до дампов теплилась надежды что и у тебя нето подобное. Но увы и ах.

У меня все разделы повреждены? Я к тому что, на что ориентироваться при восстановлении, там будут файлы со всех разделов (в куче) или только с некоторых (и на файлы с других разделов не стоит расчитывать)?


Спасибо за ответ.

0

King Tubby

Чем лучше восстанавливать? DMDE, из поиска по NTFS?

Да, в общем то, можно (и нужно) пробовать разным ПО.
Тем более что DMDE восстанавливает по структурам ФС, но есть ещё и восстановление по сигнатурам - то есть когда нет записи нет, но файл находится по характерным сигнатурам - актуально для первого (единственного) фрагмента файла (есть исключения, но это с кучей оговорок).

Как искать-то?

Ответ не описать в двух словах, поэтому постараюсь ответить, но попозже.

У меня все разделы повреждены?

Глубоко лог поиска не расскапывал, но наиболее оптимистичный второй, чуть менее - третий, с четвёртым воообще не могу пока сказать.

Сообщение от King Tubby там будут файлы со всех разделов (в куче) или только с некоторых

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

0

Ответ не описать в двух словах, поэтому постараюсь ответить, но попозже.

Хорошо.

Я про "рельсы" читал, но не знаю как там реализован виртуальный HDD: опять же - где он у тебя располагался (на внешнике или на внутреннем).

Ну смотри, на внешнем, было 3 раздела, на одном из них лежал образ виртуального HDD, он в параллелях идет под разрешением .pvm . В самих параллелях уже задвался развер этого виртуального диска. Например, 100гб. Образ на внешнем сжирад 100гб, в самой винде на виртуалке, я уже разбил этот 100гб на 2 раздела, например 40 и 60. И помимо них еще был доступ к "обычным" разделам самого HDD. Вот так все накручено

Я тут подумал, если удастся найти целым этот образ, то можно будет восстановить больше инфы.

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

0

King Tubby

на одном из них лежал образ виртуального HDD,

Млин, в деле восстановления важна любая мелочь, а тут даже "неизвестно" на каком из трёх.

в самой винде на виртуалке, я уже разбил этот 100гб на 2 раздела,

Я не знаю какова структура "паралельного" виртуального HDD, поэтому могу провести лишь прикидки на основе той же VMware (по моим сведениям это актуально и для VirtualBox). Так вот, в этих виртуалках записи NTFS присуствуют в явном виде. То есть, если на разделе NTFS присутствует виртуальный HDD с двумя разделами NTFS, то Поиск NTFS в DMDE найдёт все эти записи - причём последовательные записи в самой виртуалке, на физическом винте, в случае использования не зафиксированного сразу и фрагментированого файла, чаще всего разбросаны хаотично. Что привносит сумятицу в хаос.
И скорей всего это актуально и здесь - более 1000 найденных "томов" являются косвенным доказательством этого.

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

Конечно же можешь (на другой носитель). Более того если существует такая возможность - проверяй их на предмет целостности. Потому как при таком "взрыве на мусорке" может оказаться что в целый файл внедрены фрагменты каких то других данных.
Если будешь работать с DMDE (или каким то другим ПО, умеющим работать с диском напрямую (*)) - для надёжности можешь сделать MBRoff.
(*) Имеется в виду что есть программы, которые могут работать лишь с прописанными в винде томами. В случае MBRoff такие не смогут найти их.

0

И скорей всего это актуально и здесь - более 1000 найденных "томов" являются косвенным доказательством этого.

И с ними ничего не поделать? Собрать вместе как-то например .

- для надёжности можешь сделать MBRoff.

Нажал на кнопку MBRoff и ужаснулся, это вообще нормльно? Пишет что разделы удалены. И еще что то поменялось в таблице секторов.

Если нормально - дальше жать красную кнопку "применить"?

Миниатюры

   

0

Жми, не боись.

0

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

Изображения

 

0

В принципе, можно попробовать уменьшить число дампов, отсеяв их по принципу принадлежности к MFT.
Например по дате создания. Тут главное не ошибиться с этим признаком - в идеале, знать дату кода раздел форматировался. Пока что могу исходить из предположения что фрагмет начинающийся с 4-ой записи, начинающийся в секторе где должна была быть 0-вая, относится к нужному разделу. Если что, у него дата 2013-11-02 - ничего не напоминает? И этот критерий можно использовать для поиска.
Небольшой ликбез.
В скриншотах разные примеры 0-вой записи.
norma - нормальная запись. Салатным выделены характерные сигнатуры, по которым можно её отличить. Синим выделено то, что относится к дате и что собственно можно поискать (в паре с характерными признаками).
bad_head - у записи повреждён заголовок, хотя наблюдается характерная сигнатура (салатновая рамка). На этом же скриншоте (взят из реальной ситуации) видны вкрапления мусора по всей записи (выделил лишь часть), в том числе и в характерной.
sdvig - реальный пример и недавнего случая. Запись целая, но сдвинута относительно её правильного расположения.

Задание.
Найти 0-вую запись у которой требуемая дата.
Для этого открываешь физический диск и запускаешь поиск строки.
В поле Hex заполняешь как на скриншоте searh.
Когда сектор найдётся осматриваешься на предмет характерных сигнатур.
В том числе с учётом сдвижки от начала сектора. Лучше всё это просматривать при полностью развёрнутом экране и так, чтобы был виден сектор выше - потому как заголовок може уйти туда.
Заодно можешь обратить внимание на номер сектора (сравнить со списком из сообщения ранее).
Итак, если найдено требуемое, то делаешь дамп этого сектора + 10 последующий. Учитывая что сдвиг может быть вперёд, нужно сдвинуться на него и сделать дамп.
После этого продолжаешь поиск (нажимаешь F3). И делаешь поиск до тех пор, пока сектора не будут больше сектора 525006847.

Миниатюры

     

 

0

9285,
Мдаа, это мощно! Прочитал раза 4 - более-менее понял, но не до конца Пока чуть позже сделаю:

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

И тд.

Сейчас восстанавливаю в MDME что можно восстановить (мб еслм восстановлю необходимое, то дальнейший поиск можно будет отменить).
Есть нормальные жипеги которые работают, есть такие что нормальное имя и разрешение и размер - но не пашут, повреждены. Прикол в том, что музыка например, все 50 гб нормально восстановились. Жалко, ведь её можно скачать в интернете, а личные даныне - нет.

Если что, у него дата 2013-11-02

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

sdvig - реальный пример и недавнего случая. Запись целая, но сдвинута относительно её правильного расположения.

Я так понимаю, в этом случае все легко лечится? но у меня ситуация другая..

Пытался несколько раз написать как и что делать, но так и не смог раскрыть это дело полностью,

Да я вообще огромнейши благодарен тебе, просто нет слов!

0

В самом первом сообщении я тебе не просто так написал про ломанную - в них как раз возможно что файлы после восстановления не открываются. Это просто для напомнить - ты же уже другой (?) пользуешься.
Опять же:
1. Надо обращать внимание на значки http://dmde.ru/manual/filepanel.html
Потому что есть разница какой восстанавливается - может ты удалённый.
2. В результаты поиска могут вкрадываться и "левые" записи.
Поэтому есть разница в восстановлении по результатам поиска и по MFT (в случае когда возможна её реконструкция".
3. Уже упоминал о возможном сдвиге в данных. А ещё может быть и мусор.
В любом случае надо смотреть что в теле файла. Если это реально картинка, то есть проги, которые могут вылечить её (при некоторых условиях).
Да и ещё не забывай про возможность восстановления по сигнатурам.

Что касается даты. Я не могу гарантировать, но пока что во встреченных мною в рабочих записях дата соответствовала дате в компе (бывают же и часы сбиты).
И этот момент всегда учитываю при патчевании. Хотя некоторые используют имеющийся у них шаблон - в этом случае другая дата может сбивать с толку в случае возможных в дальнейших проблемах.

Я так понимаю, в этом случае все легко лечится?

В деле восстановления нельзя что то гарантировать 100%. Предположим что запись сдвинулась назад и она занимала почти два сектора. Соотвественно часть из них пострадает. Да и нередко тот же "мусор" вклинивается.

0

Пользуюсь пока бесплатной, ключ пока-что не покупал, справляюсь с лимитом фриварной.
1.Видел. Обращаю внимание на них.

Сообщение от 9285 но пока что во встреченных мною в рабочих записях дата соответствовала дате в компе

ЧТо это значит?

Олсо, вот скриншот, нашел ту страку как на твоем скрине. Нашлось очень быстро.


Пока с этим поиском и восстановлением в DMDE, не стоит пользоваться всякими R-Studio, GetDataBack, да? Ведь они работают по другому принципу, как ты выше писал, и могу что то нарушить!?

Миниатюры

 

0

ЧТо это значит?

Это значит что если сегодня в како то компе будет дата 9 мая 1945 года, то в записях отформатированного сегодня раздела будет фигурировать именно эта дата, а не та что в реалии.

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

Можешь работать с любым ПО, которое не занимается изменением данных на диске. Указанные тобою в этом не замечены, хотя .... :
- я всегда подразумеваю оригинальные версии программ, а не ломанные или какие либо говносборки
- в R-studio, в настройках можно включить режим записи на диск, но это ещё надо найти где.

Добавлено через 19 часов 15 минут

Сообщение от King Tubby И с ними ничего не поделать? Собрать вместе как-то например

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

0

Таксс, пока что вроде восстановил большую часть того что нужно с помощью R-Studio, так чот сейчас можно тормознуть с секторами и DMDE, может и без этого обойдемся.

Позже отпишу по результатам.

PS. Кстати, житейский совет, используемый мною - виртуальные винты хранить на отдельном разделе.

Принял, олсо, я так понял, теперь форматировать и делать разделы лучше только из под венды? Ну когда вся эта канитель закончится и я буду делать формат и разбивку на разделы. Лоу формат тут нужен?

PPS. На этом же разделе у меня хранятся и все дампы различных случаев с разных форумов - чтобы не мусорили на других.

Зачем ты коллекционируешь дампы?

0

Ну когда вся эта канитель закончится и я буду делать формат и разбивку на разделы.

Если тебя устраивают размеры томов, то нет смысла в переразбивке. В любом случае, если от харда ничего не нужно будет форматируй полным форматом средствами винды (7-ки или 8-ки).

PS. Дампы хранятся как трофеи.
Шутка. На самом деле я же тебе показал реальные примеры. Откуда мне их взять. Смоделировать? Не очень удачное решение.
Плюс, бывают очень интересные случаи, которые я моделирую и пробую различные способы решения, в том числе те, которые возникают в более позднее время.

0

Кстати, вот есть файлы восстановленные, .png например, размером в 700, 900 mb, при том картинка там присутствует а размер такой громадный. Чем это обусловленно? На самом деле там не пнг а какаой-нибудь образ или архив с неправильным расширением или пнг с "не правильным" размером?

АПД: Открываются они моментально, так тчо наверное все таки что то с размером. Думаю 400мб картинка, вьювер бы просто подвис загружая её.

0

King Tubby
Могу попробовать обьяснить ситуацию, в меру своего (поверхнстного) понимания сигнатурного поиска
Недавно на руборде был случай, в котором восстанавливаемые данные занимали места больше, чем их было.
И сам я с подобным сталкивался - где то есть скриншоты doc-ов, jpeg-ов и т.п. размерами с гигагабайт, а может и больше. Причина этого в алгоритмах поиска по сигнатурам, и именно в конкретных программах (их версиях).
У некоторых типов файлов есть характерные участки, чаще всего в начале файла. Программа, видя такую сигнатуру считает что это начало файла. А вот дальше уже надо определить конец файла. Хорошо если есть сигнатура в конце - тогда близжайшая такая и будет принята за конец. Хуже если таковой нет - в таком случае некоторые программы могут считать концом файла сектор предшествующий другой известной сигнатуре.
посмотрел бегло тела нескольких png-шек и увидел характерную сигнатуру в конце файла. И если оно реально характерно для этого типа файла, то или программа не в курсе этого (*) или файл фрагментирован.
В случае фрагментации может получится что между его началом и концом может вклинится фрагмент другого файла или нескольких, главное чтобы они не имели известных сигнатур. Соотвественно восстановится файл с размером от начальной и до конечной сигнатуры.
(*) этот вариант мне видится более логичным. Потому что я согласен с версиях что реально такой большой файл завесил бы просмотрщик. С другой стороны, если просмотрщик знает о сигнатуре конца файла, и оно где то в начале - он может показывать только этот фрагмент
Можешь сам проанализировать ситуацию.

Миниатюры

 

0

Кстати:
- какой версией R-studio пользовался?
- описанное выше наглядно показывает преимущество восстановления по данным файловой системы.

0

Решил провести эксперимент на скорую руку. В виртулке создал диск 1 гб, отформатировал его (букву у диска забрал). Затем в дисковом редакторе записал два png файла.
1-й - в оригинале
2-й - сначала в оригинале, потом перенёс последний сектор на 10 секторов далее а в эти 10 секторов записал шаблон.
Файлы взял небольшие чтобы с ними могла работать демоверсия не так давно скачанной R-studio.
В результате сканирования найден оба файла. Но каков размер второго?
Он больше размера самого раздела.
И это делает одна из самых распиаренных программ.
В этой виртуалке у меня недавно тестировалась ещё одна программа, которую участник другого форума очень нахваливал (на самом деле там тоже достаточно печально). Решил проверить ей.
Найдены оба файла с нормальными размерами. Внутренний просмотрщик проги первый показал нормально, второй с ошибкой. Тем не менее, восстановленный 2-ой файл в штатном вьювере показался нормально.
Есть набор скриншотов, но я приведу лишь один сводный, в котором показано какие реально размеры файлов и какой найден.

Миниатюры

 

0