» Пропал диск. Восстановление таблицы разделов (не данных) - 2

Цитата:

По поиску нашлось что все три относятся к $DATA из MFT

Это и без поиска понятно. 128 атрибут (в прогах 80-й) и есть $DATA и он есть в записях.
Вот посмотри на скриншоте я выпрал 348 запись.
Чёрная строка и есть та самая дата и если ты нажмёшь пробел, то увидишь содержимое этих значений.
В случае если файл резидентный (очень маленький) там будут данные файла. В случае неризедентного - размер, ранлист и т.п. (для файла). Ну а чуть выше - выделено зелёной рамкой - имя файла.
В принципе, можешь позаходить в каждую из проблемных записей и сохранить её дамп (2 сектора) и выложить здесь.

9285

В последних двух (т.е. 11003, 11053) Размер и Занято равно 0 и во всех трёх ничего кроме $DATA и нет и там хранится какая то инфа о кластерах, (какой-то список с "занято кластеров" и"начинается с", также там "сжатие" "занято", "размер" и т.д.) (ранлист?)

Добавлено:
Взвесив важность данных на томе, я все-таки решил что стоит рискнуть прогнать chkdsk /f на поврежденном томе - выдало как и полагалось больше ошибок (некоторые непонятные,но похоже все они были в файлах небольшой важности), чем оно нашло при чтении, потом появился скрытый каталог found.000 с файлами откудато (?) и в конце-концов после фикса этого тома я прогнал тоже самое на первом томе C, и на этом томе пришлось запускать аж 2 раза для результата - фиксило битовую карту 2 раза и уменьшало дескрипторы безопасности.

в конце я смонтировал все тома на чтение, прогнал проверку на всех для уверенности и теперь я перенесу всё нужное(а почти всё оказалось неповрежденным судя по всему) и разобью хард по нормальному и отдам на ту машину и уже неважно HPA или нет там,должно все работать

P.S.: слава богу хард <1Tb ато бы отгрёб сполна с этим HPA как в той теме...

P.P.S.: у тебя какая-то новая Alpha DMDE

спасибо за помощь! возьму за правило впредь регулярно прогонять chkdsk везде, где только можно

fractalzZz

Цитата:

возьму за правило впредь регулярно прогонять chkdsk везде, где только можно

Не стоит поступать так опрометчиво.
По крайней мере если уж проверять то сначала в режиме только чтения.

Цитата:

у тебя какая-то новая Alpha DMDE

Кому то же надо тестировать новые возможности программы.

9285

Цитата:

Не стоит поступать так опрометчиво.
По крайней мере если уж проверять то сначала в режиме только чтения.

Дык именно чтение ж, ато после недавних прогонов на всех томах оказалось что ошибки и на другом харде (опять битовая карта и bitmap поврежден) а я и не зналь...


Цитата:

Кому то же надо тестировать новые возможности программы.

неплохо бы чтоб была поддержка ext2/3/4 ещё

fractalzZz

Цитата:

неплохо бы чтоб была поддержка ext2/3/4 ещё

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

Прочесал все 2 Тб в DMDE поиском NTFS, получил 91 том. Нашёл пропавшую папку, попытался восстановить отдельные файлы - почти каждый восстанавливается битым, особенно большие. Отсюда вопрос по алгоритму переходов по правильной цепочке частей восстанавливаемых файлов. Там есть что-то про подключение пропавших фрагментов через редактирование ранлиста $DATA, но как именно? И какие есть тонкости?

Добавлено:
Или мне нужны иные методы?

У меня microSD карта на 16ГБ класс 4 Kingston подключаю к компу через SDHC кардридер.
Я намутил чегота с фарматированием так что теперь залить большие файлы не могу на нее, только до 3-х ГБ Хотя обьем пишет 14,7 ГБ. Форматил ее несколько раз в NTFS и други типы... непомогло.

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

Bartonlim
А причём здесь восстановление таблицы разделов? Может лучше поузнавать по поводу возможностей твоей карты, картридера, ОСи?
Ограничение по записи в зависимости от размера файла присуще FAT32. Наверное ты что то перемудрил. Отформатируй всё таки в NTFS (или exFAT).

9285

Цитата:

Я могу сказать как бы сделал я. Но если на диск происходят некорректные записи то работать через глючный интерфейс не стал бы и подключил бы винт напрямую к SATA (опять же, если там такой разьём) на материнке, или в нормальный контейнер. После чего вычитал бы в посекторку и работал бы уже с ней.

В общем купил я новый винт. Сделал загрузочную флешку HDCloneом. Перезагрузился и сделал посекторную копию. И теперь новый винт тоже не открывается аналогично старому. И не форматируется средствами виндоуз. Просто праздник какой-то.
Один нюанс. Новый винт тоже терабайтник оказался на несколько мегабайт меньше старого. HDclone об этом упомянуло и сказало вроде что недопишет или перепишет часть информации. Что посоветуете? Как винт отформатировать? Может есть более злые программы для этого, чем виндоуз.

VyacheslavM
1. Я писал о посекторке на диск обьёмом не меньше проблемного.
Причём здесь есть два момента.
1.1. Посекторка на диск. В этом случае размер должен быть не меньше.
1.2. Посекторка в файл. В этом случае размер диска должен быть чуть больше чем в п.1.1, так на этом винте ФС зоздаст свои служебные файлы.
2. Даже если отбросить написанное в п.1 - запись посекторкной копии даёт возможность отката в случае неудачного лечения. НО никаким образом не утраняет ошибки оригинала.
Это как выставлять претензии в неотличии абсолютному клону чего то.

9285

Цитата:

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

А какие программы позволяют делать копию в сжатом виде?

Цитата:

какие программы позволяют делать копию в сжатом виде?

Видел в WinHEX, но не проверял как оно работает.
Acronis Disk Director - только там внимательно смотри где надо бужет включить посекторное копирование (по умолчанию оно отключено).

В принципе, можно и не делать in-place восстановление - в таком случае просто восстанови нужные данные на новый носитель.

Добрый день! Помогите восстановить раздел или хотя бы данные...
Хотел акронисом к разделу добавить места, но во время операции на 58% выбило ошибку.
Теперь никакими средствами не получается его открыть. CHKDSK пишет, что повреждена основная файловая таблица.
Все нужные данные с DMDE - http://rghost.ru/43739991

froozzzen
Подробности будут или гадать что делалось - от чего бралось место, менялись ли типы разделов?
В принципе можешь сразу сбросить дамп сектор 372065408+100, а также запустить Поиск NTFS а участке диска в который входит и текущее положение раздела и прежние границы. Результат поиска сохрани и выложи.

9285

Был раздел около 28 гб с Хакинтошем, затем около 32 гб пустоты и заветный раздел Д. В акронисе было задание удалить раздел с хакинтошем и получившиеся свободные 60 гб прикрепить к разделу Д.

Дамп - http://rghost.ru/43746438
Поиск NTFS запустил, но результат поиска видимо не скоро будет.

froozzzen
Я, конечно же, догадываюсь что 60 гигов были до проблемного раздела, но может всё таки будут точные данные?
В процессе поиска можно делать помежуточные сохранения. И их достаточо часто хватает для того, чтобы понять суть проблемы.

Добавлено:
В предыдущем ответе был запрос дампа не тех секторов ("сбило" с толку смещение букв) - реально нужен дамп ссекторов 633023152+100.

9285

Скажите какие точные данные нужны.

Вот дамп и лог поиска http://rghost.ru/43755600
Вроде бы поиск дал результат с началом 125873208, размер 756388328, но там по моему ещё файлы со следующего раздела

froozzzen
Многие вещи тебе кажутся понятными просто потому, что ты всё это знаешь. Но ведь другим неведомо что было раньше, что намечалось и даже то, какие такие файлы и где лежали.
И данные дампов, как и поиска не очень сильно проясняют ситуацию. Даже более, как раз таки том с началом в 125873208 очень даже правдоподобен, и даже есть "наброски", которые наводят на мысль о том что этот раздел был сдвинут дальше а на его месте создан имеющийся теперь 60 гиговый раздел. Это конечно же не точные выводы, но некоторые данные подводят к этому.
Хотя, описаное тобою тоже могло быть, но чисто гипотетически - прописывается бутсектор в новом месте, но не прописывается в таблицу разделов, при этом возникает раздел, который ты имел в расчёте как нераспределённое место. Но такое как бы не должно быть, потому как операции делаются последовательно (поэтапно). Хотя от тварений Акрониса можно ожидать чего угодно. Кстати что за версия?
PS. Предварительный диагноз не очень утешительный, впрочем он характерен при таких срывах партмагоидов. Востановление in-place (данных а не таблиц разделов) очень проблематично и не ко всей части данных. Лучше заняться восстановлением важных данных на иной носитель, обязательно проверять их целостность.
PPS. Нарисуй просто, но понятно структуру разделов ранее и как хотел сделать.

9285
Извиняюсь, упустил указать пару моментов.

В общем, дано: С 60, Hackintosh - 28, free - 32, D - 300, E - 277
После сбоя остается так же само, только у раздела D показывает 0 свободного места, хотя было пару десятков Гб и он не открывается.
Потом я раздел хакинтоша убил. Из получившихся 60 Гб сделал новый раздел F. (Не спрашивайте зачем, сам не понимаю. Голова не варила)

Версия акрониса 11-ая.

http://rghost.ru/43756928 - вот что показывает когда нахожу этот найденный раздел. Желтый папки были на D, синие находятся на E.

И кстати, без разницы восстанавливать раздел или просто данные на другой диск. Диск для заполнения восстановленной информации имеется.

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

Цитата:

синие находятся на E

Синие или всё таки зелёные?
Синие это папки метаданных - http://dmde.ru/manual/filepanel.html и они относятся к текущему разделу.
Если же речь о зелёных, то не могу подсказать точно, а лишь предположить - папки ранее были на разделе или ранее делались манипуляции с разделами, а следы остались. Или может это последствия нынешнеих сдвигов.
Фактически, сейчас можно удалить 60-ти гиговый раздел, прописать 360-гиговый и сформировать для него бутсектор - тем более по ранлисту MFT расположена имено относительно указанного ранее сектора. Но не факт что все записи MFT успели перепрописаться относительно нового начала. А если наоборот - часть записей записалась на новое место, но потом ты перезаписал их создав новый рраздел.
После таких перетрубаций чекдиск (а без него не получится очухать раздел) может наломать немало дров.
Поэтому решай сам что делать. Даже если делать in-place то самые критичные данные нужно восстановить до исправлений; и обязательно проверить их целостность. И это займёт меньше места, чем создание посекторки 360-гигового участка.
В случае же не in-place, в идеале, поудалять эти два раздела, обнулить эти 360 гигов чтобы старые ошмётки не мешались в последующем и создать раздел по новой, после чего перебросить на него восстановленные ранее файлы. Впрочем, это же можно сделать после попытки in-place .

PS. Восстановление файлов подразумевается с помощью DMDE, в найденных томах. Преимуществено в том, который найден в секторе 12837208.

9285
Ой, туплю. Да, зелёные папки на разделе Е.
Мне больше нравится вариант с восстановлением данных на другой носитель и форматом 360 гигов.
Как я понял, чтобы нормально восстановить всё за одну операцию нужно купить DMDE?

Цитата:

Как я понял, чтобы нормально восстановить всё за одну операцию нужно купить DMDE?

А ты уже пробовал восстаавливать? Всё нормально?

Чтобы не создалось впечатление о протежировании этой программы, имеются и другие варианты.
1. Бесплатные рековерилки, в том числе и Photorec со своей спецификой востановления (по сигнатурам).
Их перечень и возможности есть в теме посвящённой восстановлению данных.
2. Небесплатные другие рековерилки, стоимость которых не такая уж и маленькая.
3. Можно попробовать полнофункциональную старую версию DMDE, которая есть на сайте.
Тут важно качество восстановления - смогут ли они в такой запутанной ситуации отрабоать корректно.
Фактически, твоя ситуация очень хороша для проведения сравнения возможностей рековерилок.

Можно скорректировать структуру раздела и тогда прогам (логически) будет проще найти и восстановить данные.

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

Так что сам выбирай что тебе приятней.

9285
Помогли восстановить Active@ File Recovery и DMDE старая версия. R.saver нашёл информацию, но восстановленные файлы не открывались.
Спасибо большое за помощь)

Слетела gpt-разметка.
Винт 3тб, гпт, 6 разделов

помогают здесь или в другой ветке?

9285

Привет. Помоги, пожалуйста, решить проблему с $MFT.

Проблема возникла сразу же после твоего патча к первому диску. Патч содержал исправление $Volume, где, в том числе, была прописана label: "Recovery".
А суть проблемы в следующем: если изменить эту метку (например, просто нажав на свойства диска C: с этой label, на любую другую, то я начинаю отгребать от системы серьёзные хитроумные проблемы и страшные ошибки в журнале событий, что в Vista, что в Win7 - одинаковые, которые неисправимы CHKDSK)

У меня были мысли о наличии контрольной суммы или чем-то таком, что мешает выставить другую метку.

Что это может быть ?

fractalzZz
Попробовал в виртуалке этот патч. Такого как описываешь ты нет. Хотя да, чекдиск нашёл какю то ошибку, но успешно её исправил.
В принципе $Volume можно взять от любого работающего раздела. Главное чтобы версия была 3.1 (прописана в 70 атрибуте) - а это тома практически всех современных версий Windows.

9285

А как это работает ?

Допустим я беру $Volume с третьего тома. Куда мне его вносить: в $MFT или $MFTMirr или сразу в обе ?

Что куда пишется первым и когда: $MFT > $MFTMirr или наоборот ?

upd:

Обнаружилась закономерность:
1) если оставить кол-во символов в label неизменным (8), но изменить сами символы, то ошибки не возникают.
2) если символов будет больше - 100% ошибки, причем CHKDSK иногда видит ошибки в зеркальной $MFT, но после исправления больше ошибок не видит, а толку от этого мало для нормальной работы системы...
3) если же меньше, то CHKDSK находятся ошибки в зеркальной $MFT на системном томе, но я ещё не перезагружался и не проверял, что будет, если запустить их на исправление, хотя в этом варианте шансы на успех велики, так как система по крайней мере работает стабильно ещё в отличие от варианта 2) где я без понятия даже, что делать и почему это нарушает целостность NFTS.

Ещё как-то подозрительно выглядят начала $MFT на всех томах диска - вместо FILE0 идёт FILE*

fractalzZz
Отключи букву диска в котором будешь менять записи. Вноси и в MFT и в зеркало. После изменений можешь вернуть букву назад.
Насчёт неадекватного поведения системы ничего не могу сказать.
Что касается подозрительности, то не стоит беспокоится. FILE - заголовок записи MFT, последующее значение указывает на место расположения массива маркеров. И оно в каждом случае индивидуально.

9285

Поэкспериментировал с этим от разных томов этого же диска. В конечном итоге единственным улучшением после всех проверок и вариантов стало то, что теперь максимальная длина label, при которой ужасные ошибки не появляются равна 12 символов, а не 8, как раньше, а если больше, то всё по-старому. Меньше тоже ок.

С одной из меток даже получилось так, что том стал виден как RAW, а DMDE никаких ошибок не показывала.

Вот архив с $Volume из этого варианта, проверь у себя также на системном томе:
http://rghost.ru/44114525

Форсировать ошибки легко, достаточно запустить создание "Точки Восстановления" на томе.

С виду это похоже на проблему с $Volume, либо вообще где-то в $MFT, но куда копать и как теперь восстанавливать систему, если это не $Volume я без понятия даже , ибо даже CHKDSK проблем не видит.

fractalzZz
http://rghost.ru/44117377 - попробуй этот шаблон записать в $Volume
Эксперимент я сделаю, но позже. Такое поведение системы присуще лишь при такой метке на системном разделе или на любом к которому обращается система?
ИМХО, это косяки самой системы а не из за метки тома.