» Восстановление разделов и информации на HDD (часть 8)
The_Immortal
В первом дампе сектора прописаны каким то шаблоном.
Что могло перезаписать бутсектор, который исходя из записи в таблице разделов долже быть в 63-ем секторе.
Во втором дампе видна FAT таблица. Судя по результатам поиска, вторая копия должна начинаться в секторе 17773. Сделай дамп секторов 17730+50 и 32830+20.
И если это так, то как то не очень "правильно" такое удаление таблицы от бутсектора. То есть такое возможно, но не гламурно.
Поэтому, если флэшка не какая то специфичная - переразметь её с нормальными значениями.
В первом дампе сектора прописаны каким то шаблоном.
Что могло перезаписать бутсектор, который исходя из записи в таблице разделов долже быть в 63-ем секторе.
Во втором дампе видна FAT таблица. Судя по результатам поиска, вторая копия должна начинаться в секторе 17773. Сделай дамп секторов 17730+50 и 32830+20.
И если это так, то как то не очень "правильно" такое удаление таблицы от бутсектора. То есть такое возможно, но не гламурно.
Поэтому, если флэшка не какая то специфичная - переразметь её с нормальными значениями.temp9285,
Цитата:
Цитата: Я, конечно, вижу сходство, но где признаки FAT32?
Цитата:
Цитата:
Сделай дамп секторов 17730+50 и 32830+20.Дампы.
Цитата:
Во втором дампе видна FAT таблица.А как Вы её увидели? Раскройте секрет, пожалуйста
Я, конечно, вижу сходство, но где признаки FAT32?Цитата:
Поэтому, если флэшка не какая то специфичная - переразметь её с нормальными значениями.Эм... А как это правильно сделать?
The_Immortal
Цитата:
Да какой же это секрет, если в куче толмудов описаны, характерные для начала FAT32, символы, которые видны на скриншоте в самом начале сектора.
В дампах что то не нашёл начала FAT2, поэтому тебе набольшое задание.
Открой диск в DMDE, затем Сервис-Найти строку - в поле HEX набери F8FFFF0F, включи галку смещение, значение оставь 0 и смотри в каких секторах есть такое.
В 2715 есть, интересует следующее нахождение. Укажи номер сектора. Попробуй поискать ещё.
Цитата:
Слить данные, удалить раздел, создать новый средствами винды и отформатировать. Посмотреть в каком секторе начинается раздел, но более важно где сами данные - это можно увидеть в карте кластеров.
Добавление:
Дампы идентичны, хотя в именах фигурирует разное число секторов - это как понимать?
Цитата:
А как Вы её увидели? Раскройте секрет, пожалуйста
Да какой же это секрет, если в куче толмудов описаны, характерные для начала FAT32, символы, которые видны на скриншоте в самом начале сектора.
В дампах что то не нашёл начала FAT2, поэтому тебе набольшое задание.
Открой диск в DMDE, затем Сервис-Найти строку - в поле HEX набери F8FFFF0F, включи галку смещение, значение оставь 0 и смотри в каких секторах есть такое.
В 2715 есть, интересует следующее нахождение. Укажи номер сектора. Попробуй поискать ещё.
Цитата:
Эм... А как это правильно сделать?
Слить данные, удалить раздел, создать новый средствами винды и отформатировать. Посмотреть в каком секторе начинается раздел, но более важно где сами данные - это можно увидеть в карте кластеров.
Добавление:
Дампы идентичны, хотя в именах фигурирует разное число секторов - это как понимать?
temp9285,
Цитата:
Цитата:
7258690
13799759
13819684
13859377
13859699
14021288
14425095
14426037
14427447
14704539
Делать по всем дампы? Правда, их даже как-то маловато нашлось... Судя по логу полного сканирования FAT0-нахождений было обнаружено 1246 штук
P.S. Такое кол-во FAT-таблиц - это нормально?
Цитата:
Дампы идентичны, хотя в именах фигурирует разное число секторов - это как понимать?Действительно... Странно, вроде бы выпивал, но это было вчера :/ Переделал, прошу простить...
Цитата:
В 2715 есть, интересует следующее нахождение. Укажи номер сектора. Попробуй поискать ещё.Нашелся уже обнаруженный ранее Вами 17773 сектор. А также следующие:
7258690
13799759
13819684
13859377
13859699
14021288
14425095
14426037
14427447
14704539
Делать по всем дампы? Правда, их даже как-то маловато нашлось... Судя по логу полного сканирования FAT0-нахождений было обнаружено 1246 штук
P.S. Такое кол-во FAT-таблиц - это нормально?
The_Immortal
Цитата:
Если хочешь судить по результатам поиска, то тогда нужно соотносить с числом найденных томов FAT.
А чему относятся все остальные (кроме 17773) можно посмотреть по карте кластеров, то ли принадлежат к какому то файлу (в изошках бывают такие), то ли артефакт.
В общем то ситуация ясна.
Можешь взять бутсектор от какого то FAT32 раздела, прописать в сектор 63 (это чтобы соотвествовать записи в РТ, а потом изменить на свои значения поля, отмеченные синим на рисунке из архива http://rghost.ru/6m4M2FHNT - остальные проверь. Серийный номер можешь перебить, чтобы не было путаницы в хранилище данных о дисках. Пропиши скорректированный сектор и в 69-й сектор.
На всякий случай
, в архиве уже готовый патч.
Цитата:
Правда, их даже как-то маловато нашлось... Судя по логу полного сканирования FAT0-нахождений было обнаружено 1246 штук
Если хочешь судить по результатам поиска, то тогда нужно соотносить с числом найденных томов FAT.
А чему относятся все остальные (кроме 17773) можно посмотреть по карте кластеров, то ли принадлежат к какому то файлу (в изошках бывают такие), то ли артефакт.
В общем то ситуация ясна.
Можешь взять бутсектор от какого то FAT32 раздела, прописать в сектор 63 (это чтобы соотвествовать записи в РТ, а потом изменить на свои значения поля, отмеченные синим на рисунке из архива http://rghost.ru/6m4M2FHNT - остальные проверь. Серийный номер можешь перебить, чтобы не было путаницы в хранилище данных о дисках. Пропиши скорректированный сектор и в 69-й сектор.
На всякий случай
, в архиве уже готовый патч.Цитата:
Информация о заголовке файла HEX: 4F 54 54 4F 00 ASCII: OTTO
Получается что заголовок файла найти можно.
Теперь вопрос в том, есть ли в файле данные о размере или есть ли сигнатура конца файла.
Но это актуально для нефрагментированных файлов.
Цитата:
А вот с ависинтом сложнее...
Исходя из описания в википидеи - это скрипт, и в нём что то типа обычного текста. Соотвественно, если файл не располагался резидентно в MFT (*) и можно видеть это содержимое в хекс редакторе, то искать по известным значениям. (*) С резидентными можно попрощаться.
Добрый день!
А не подскажешь, как в DMDE искать можно эти файлы по данным?
Когда восстанавливал Ontrack EasyRecovery Enterprise, он понакидал много файлов с расширениями. которых у меня не было, возможно среди них были и нужные...
temp9285, у Вас на скрине и в патче для поля "Total sectors" разные значения - какому верить? Кстати, а откуда Вы взяли эти значения вообще? Из здоровой FAT32 таблицы?
Цитата:
Цитата:
И как быть с 17773? Мы его просто игнорируем теперь?
P.S. Я не издеваюсь и не троллю, а, пользуясь Вашим альтруизмом и терпением, по-прежнему пытаюсь хоть немного въехать, чтобы в будущем меньше Вас доставать. Правда, это "въезжание" дается с очень большим трудом.
Кстати, а откуда Вы взяли эти значения вообще? Из здоровой FAT32 таблицы?Цитата:
Серийный номер можешь перебитьА где он там сидит?
Цитата:
Пропиши скорректированный сектор и в 69-й сектор.Хм... Если 63-ий сектор фигурировал ранее, то откуда Вы узнали про 69-ый?
И как быть с 17773? Мы его просто игнорируем теперь?
P.S. Я не издеваюсь и не троллю, а, пользуясь Вашим альтруизмом и терпением, по-прежнему пытаюсь хоть немного въехать, чтобы в будущем меньше Вас доставать
. Правда, это "въезжание" дается с очень большим трудом.The_Immortal
Упс. Действительно, скриншот поместил не тот - так что актуален патч.
Хотя есть ещё одна цифра - 30871488. Это значение основано на значениях в таблице разделов.
Значение в патче (как и некоторые другие) взято из результатов поиска - в контекстном меню тома есть "Открыть параметры тома".
Цитата:
Из всё тех же талмудов - обычно копия бутсектора смещена на 6-секторов; и это значение прописано в бутсекторе.
Цитата:
А что предполагал делать с ним? Дамп этого сектора запрашивался чтобы убедиться что там начинается FAT2.
Упс. Действительно, скриншот поместил не тот - так что актуален патч.
Хотя есть ещё одна цифра - 30871488. Это значение основано на значениях в таблице разделов.
Значение в патче (как и некоторые другие) взято из результатов поиска - в контекстном меню тома есть "Открыть параметры тома".
Цитата:
Если 63-ий сектор фигурировал ранее, то откуда Вы узнали про 69-ый?
Из всё тех же талмудов - обычно копия бутсектора смещена на 6-секторов; и это значение прописано в бутсекторе.
Цитата:
И как быть с 17773? Мы его просто игнорируем теперь?
А что предполагал делать с ним? Дамп этого сектора запрашивался чтобы убедиться что там начинается FAT2.
temp9285, применил патч - всё замечательно теперь Спасибо огромное!
Цитата:
Цитата:
Цитата: В дампах же такого нет...
Спасибо огромное! Цитата:
Дамп этого сектора запрашивался чтобы убедиться что там начинается FAT2.Вопрос глупый, но всё же - для чего две таблицы FAT тогда? Имею в виду 2715 сектор и 17773? Вторая, как Вы писали выше, это копия. Но на кой она? На всяк?
Цитата:
если флэшка не какая то специфичная - переразметь её с нормальными значениями.А это надо сейчас делать или всё в порядке теперече?
Цитата:
Значение в патче (как и некоторые другие) взято из результатов поиска - в контекстном меню тома есть "Открыть параметры тома".Вижу... Только где Вы взяли параметры моего тома?
В дампах же такого нет... The_Immortal
Цитата:
Это вопрос к разработчикам, но думаю что всё таки для резервирования. При повреждении в одной из них, можно провести анализ оставшегося и попробовать исправить ошибки.
Цитата:
Вот это уж сам решай. Я ранее уже дал ссылку по вопросу оптимизации, но есть и второй аспект нестандартной разметки - неизвестно как на неё среагирует то ли иное ПО, да даже сама винда.
Не буду утверждать, но та же семёрка предлагает провести проверку флэшки при подключении её. И это делается при отсутствии ошибок, но когда флэшка с таблицей разделов. Насколько понимаю, микрософтовцы считают что флэшка не может быть с несколькими разделами - то есть бутсектор в начальном секторе.
Цитата:
В предыдущем сообщении написал как узнать значения. Если не очень понятно - http://gluon.rghost.ru/7x8ZTc6cz/image.png
Цитата:
для чего две таблицы FAT тогда? Имею в виду 2715 сектор и 17773? Вторая, как Вы писали выше, это копия. Но на кой она? На всяк?
Это вопрос к разработчикам, но думаю что всё таки для резервирования. При повреждении в одной из них, можно провести анализ оставшегося и попробовать исправить ошибки.
Цитата:
А это надо сейчас делать или всё в порядке теперече?
Вот это уж сам решай. Я ранее уже дал ссылку по вопросу оптимизации, но есть и второй аспект нестандартной разметки - неизвестно как на неё среагирует то ли иное ПО, да даже сама винда.
Не буду утверждать, но та же семёрка предлагает провести проверку флэшки при подключении её. И это делается при отсутствии ошибок, но когда флэшка с таблицей разделов. Насколько понимаю, микрософтовцы считают что флэшка не может быть с несколькими разделами - то есть бутсектор в начальном секторе.
Цитата:
Только где Вы взяли параметры моего тома?
В предыдущем сообщении написал как узнать значения. Если не очень понятно - http://gluon.rghost.ru/7x8ZTc6cz/image.png
temp9285,
Цитата: Сейчас у меня нестандартная разметка?
В общем, сношу все данные и работаю с флешкой через DISKPART под Win 8.1: сношу раздел и создаю новый.
Цитата:
Вот это уж сам решай. Я ранее уже дал ссылку по вопросу оптимизации, но есть и второй аспект нестандартной разметки - неизвестно как на неё среагирует то ли иное ПО, да даже сама винда.Почти ничего не понял
Не буду утверждать, но та же семёрка предлагает провести проверку флэшки при подключении её. И это делается при отсутствии ошибок, но когда флэшка с таблицей разделов. Насколько понимаю, микрософтовцы считают что флэшка не может быть с несколькими разделами - то есть бутсектор в начальном секторе.
Сейчас у меня нестандартная разметка? В общем, сношу все данные и работаю с флешкой через DISKPART под Win 8.1: сношу раздел и создаю новый.
dmkov9
Цитата:
Тут основной момент - понять структуру файла, имеются ли какие то характерные сигнатуры, данные о размер файла или контрольные суммы.
По поводу того же otf-файла я указал тебе его заголовок. Других данных я не нашёл (хотя я то и не искал особо). Но заголовок даст лишь возможность найти начало файла.
Далее можно работать исходя из версии что файл не фрагментирован. Судя по паре скачанных шрифтов в начале файла есть его название (*), и в конце есть нечто (не знаю как обьяснить правильнее) отдалённо идентичное; размер файла (в "прямом" виде) не заметил, хотя он не обязательно может быть "прямым".
Если, как написал раньше BOBAH4IK, распарсить индексы то возможно найдётся инфа о размерах файлов. И если название шрифта как то сопоставимо с именем файла, то тогда можно вычитать такое количество байтов. Если файл не был фрагментирован, и угадал с именами, то получишь файл.
Несомненно, упоминаемое ранее составление карты используемых кластеров, помогло бы уменьшить диапазон поиска, но только:
- я не знаю есть ли такие программы
- насколько понимаю, на автомате не делается, а вручную перебирать все файлы это не два пальца об асфальт. Тем более нельзя исключить наличие пары (и более) идентичных файлов, одни из которых удалён. Как определить какой из них?
- всё равно не будут учитываться фрагментированные файлы (*).
(*) Чтобы быть уж точным, если файл очень сильно фрагментирован, и данные о его размещении были в расширенном аттрибуте, то не исключено что его модно найти. Но это ещё тот клубок, который размотать не так уж и просто (если возможно)
Что касается скриптов, то там ещё надо посмотреть как он выглядит - может по тексту скриптов искать.
Цитата:
Как минимум - посмотри то, о чём я написал выше.
Добавлено:
The_Immortal
Цитата:
[more=Не очень] Я не знаю уже как обьяснить чтобы было понятно. "Стандарта" как такового вроде бы нет, но если флэшка чистая (0-вой сектор пустой) винда создаёт том с началом в 0-вом секторе. Для простого применения (данных) в этом нет ничего страшного. В случае же использования таблицы разделов, начало раздела имеет значение, зависящее от используемого форматера. Например, известная по статьям утилита от HP делает его в 63-ем секторе (*).
Заводские нередко в 2048, 4096, 8192 - значение кратное (как минимум) 8-ке.
(*) у тебя такой, но вот смещения не опять же не"стандартные".
Вполне возможно что данные окажутся выровнены, но есть другой момент. Если при этой разметке ты решишь отформатировать флэшку виндой, то она сделает уже со своими стандартными смещениями и тогда уже вряд ли данные будут выровнены".[/more]
Цитата:
А не подскажешь, как в DMDE искать можно эти файлы по данным?
Тут основной момент - понять структуру файла, имеются ли какие то характерные сигнатуры, данные о размер файла или контрольные суммы.
По поводу того же otf-файла я указал тебе его заголовок. Других данных я не нашёл (хотя я то и не искал особо). Но заголовок даст лишь возможность найти начало файла.
Далее можно работать исходя из версии что файл не фрагментирован. Судя по паре скачанных шрифтов в начале файла есть его название (*), и в конце есть нечто (не знаю как обьяснить правильнее) отдалённо идентичное; размер файла (в "прямом" виде) не заметил, хотя он не обязательно может быть "прямым".
Если, как написал раньше BOBAH4IK, распарсить индексы то возможно найдётся инфа о размерах файлов. И если название шрифта как то сопоставимо с именем файла, то тогда можно вычитать такое количество байтов. Если файл не был фрагментирован, и угадал с именами, то получишь файл.
Несомненно, упоминаемое ранее составление карты используемых кластеров, помогло бы уменьшить диапазон поиска, но только:
- я не знаю есть ли такие программы
- насколько понимаю, на автомате не делается, а вручную перебирать все файлы это не два пальца об асфальт. Тем более нельзя исключить наличие пары (и более) идентичных файлов, одни из которых удалён. Как определить какой из них?
- всё равно не будут учитываться фрагментированные файлы (*).
(*) Чтобы быть уж точным, если файл очень сильно фрагментирован, и данные о его размещении были в расширенном аттрибуте, то не исключено что его модно найти. Но это ещё тот клубок, который размотать не так уж и просто (если возможно)
Что касается скриптов, то там ещё надо посмотреть как он выглядит - может по тексту скриптов искать.
Цитата:
Когда восстанавливал Ontrack EasyRecovery Enterprise, он понакидал много файлов с расширениями. которых у меня не было, возможно среди них были и нужные...
Как минимум - посмотри то, о чём я написал выше.
Добавлено:
The_Immortal
Цитата:
Сейчас у меня нестандартная разметка?
[more=Не очень] Я не знаю уже как обьяснить чтобы было понятно. "Стандарта" как такового вроде бы нет, но если флэшка чистая (0-вой сектор пустой) винда создаёт том с началом в 0-вом секторе. Для простого применения (данных) в этом нет ничего страшного. В случае же использования таблицы разделов, начало раздела имеет значение, зависящее от используемого форматера. Например, известная по статьям утилита от HP делает его в 63-ем секторе (*).
Заводские нередко в 2048, 4096, 8192 - значение кратное (как минимум) 8-ке.
(*) у тебя такой, но вот смещения не опять же не"стандартные".
Вполне возможно что данные окажутся выровнены, но есть другой момент. Если при этой разметке ты решишь отформатировать флэшку виндой, то она сделает уже со своими стандартными смещениями и тогда уже вряд ли данные будут выровнены".[/more]
temp9285, благодарю за информацию!
Сделал вот так:
Цитата:
Цитата:
Сделал вот так:
Цитата:
если флэшка чистая (0-вой сектор пустой) винда создаёт том с началом в 0-вом секторе.
Цитата:
Заводские нередко в 2048, 4096, 8192 - значение кратное (как минимум) 8-ке.Винда почему-то решила сделать как в заводе
The_Immortal
Скорей наоборот - 2048 это характерно для винды.
Теперь осталось глянуть по карте кластеров в каком номере сектора начинается любой файл (кратен ли он 8-ке).
Скорей наоборот - 2048 это характерно для винды.
Теперь осталось глянуть по карте кластеров в каком номере сектора начинается любой файл (кратен ли он 8-ке).
temp9285,
Цитата:
Цитата:
Цитата:
Скорей наоборот - 2048 это характерно для винды.А 0 - соответственно для завода?
Цитата:
осталось глянуть по карте кластеров в каком номере сектора начинается любой файл (кратен ли он 8-ке).Вроде как да. Но вдруг это случайность? И что сиё значит, что данные выровнены? А чем чревато иметь невыровненные данные на носителе?
The_Immortal
Ну ё маё, ведь писал же - для случая когда нет таблицы разделов (MBR).
И насчёт выравнивания ранее есть ссылки.
Альтруизм-альтруизмом, но он не бесконечен.
Ну ё маё, ведь писал же - для случая когда нет таблицы разделов (MBR).
И насчёт выравнивания ранее есть ссылки.
Альтруизм-альтруизмом, но он не бесконечен.
temp9285,
Цитата:
Цитата:
Цитата:
Спасибо!
Цитата:
Ну ё маё, ведь писал же - для случая когда нет таблицы разделов (MBR).Тьфу! Ну логично же...
Цитата:
И насчёт выравнивания ранее есть ссылки.Окей, поищу!
Цитата:
Альтруизм-альтруизмом, но он не бесконечен.А благодарность моя к Вам бесконечна!
Спасибо!
temp9285
Доброго времени суток. Перешел Сюда. Проблема с WD 20 efrx. Смарт-норм, Виктория-норм. Контакты чистил.
Доброго времени суток. Перешел Сюда. Проблема с WD 20 efrx. Смарт-норм, Виктория-норм. Контакты чистил.
Ironjaw
Ты всё таки, когда будет возможность, выложи скриншоты и более подробное описание - ведь не все здешние участники на кибер заходят.
Показатели SMART хорошие и это немного смущает при таких проблемах как у тебя.
Может это показатели другого диска - а проблемный один из тех, у которых (в верхней части скриншота) видны жёлтые индикаторы? Если же этого (*), то можно предположить программные (системные) ошибки или какой то глюк контроллера диска, при которых что то происходит с 0-вой записью MFT (и её копией).
В любом случае надо глянуть что там сейчас. На экране разделы наведи курсор на (основной) раздел и смотри что в фоновом окне (**) что в полях Sectors per cluster и MFT start Cluster.
Теперь рассчитай сектор начала MFT, номер которого равен 2048+(Sectors per cluster Х MFT start Cluster).
Нужен дамп этого и 100 последующих секторов.
PS. В любом случае, ты должен понимать что восстановление по месту не всегда может получится, поэтому восстанавливать самое важное на другой носитель надо в любом случае.
(*) Если всё таки этого, то можешь (после снятия дампа секторов) запустить в DMDE полное сканирование. По мере продвижения сохраняй лог поиска. Можешь выложить промежуточный результат где то через час скана.
И да, перед всем этим забери у диска (тома) букв в диспетчере дисков винды - это для того чтобы винда там ничего не понаисправляла; хотя по хорошему лучше вообще сделать MBRoff.
(**) Сделай скриншот, на котором видно фоновое окно и выложи.
Ты всё таки, когда будет возможность, выложи скриншоты и более подробное описание - ведь не все здешние участники на кибер заходят.
Показатели SMART хорошие и это немного смущает при таких проблемах как у тебя.
Может это показатели другого диска - а проблемный один из тех, у которых (в верхней части скриншота) видны жёлтые индикаторы? Если же этого (*), то можно предположить программные (системные) ошибки или какой то глюк контроллера диска, при которых что то происходит с 0-вой записью MFT (и её копией).
В любом случае надо глянуть что там сейчас. На экране разделы наведи курсор на (основной) раздел и смотри что в фоновом окне (**) что в полях Sectors per cluster и MFT start Cluster.
Теперь рассчитай сектор начала MFT, номер которого равен 2048+(Sectors per cluster Х MFT start Cluster).
Нужен дамп этого и 100 последующих секторов.
PS. В любом случае, ты должен понимать что восстановление по месту не всегда может получится, поэтому восстанавливать самое важное на другой носитель надо в любом случае.
(*) Если всё таки этого, то можешь (после снятия дампа секторов) запустить в DMDE полное сканирование. По мере продвижения сохраняй лог поиска. Можешь выложить промежуточный результат где то через час скана.
И да, перед всем этим забери у диска (тома) букв в диспетчере дисков винды - это для того чтобы винда там ничего не понаисправляла; хотя по хорошему лучше вообще сделать MBRoff.
(**) Сделай скриншот, на котором видно фоновое окно и выложи.
[more] [more] temp9285
Началось все со спонтанных ошибок чтения при заполнении диска больше, чем на 60-65% - перезагрузка, CHKDSK-исправлено. Проверка Data Lifeguard Diagnostic for Windows по смарт-норм, быстрая-норм, расширенная-выявила несколько логических нестыковок-исправила. Перезагрузка, перепроверка-все норм. Диск использовался как файлохранилище, резервное хранилище данных и резервных образов системного раздела, а также для файлообмена. Температура под нагрузкой по данным из AIDA x64 выше 39 C не поднималась. Поутихло все примерно месяца на полтора, затем снова-ошибка чтения при операции чтения-записи, перезагрузка, CHKDSK. Проверил Викторией - линейный тест чтения прямой и обратный-предупреждений не выявил. Полностью перенести всю информацию не смог-не хватило свободного объема. Начал "разгружать" диск от помойки. Появились orphaned файлы при очередной загрузке системы. В итоге CHKDSK выявил проблему с MFT. Устранил, до следующей загрузки. В очередной раз проверившись при старте системы CHKDSK не смог собрать MFT. Test disk обнаружил записи, но после восстановления ситуация осталась той же. R-studio обнаружила раздел. Директории на местах, но считать их без восстановления невозможно. Восстановлением из-под R-studio не могу воспользоваться-дефицит свободного пространства для рекавери. Прошу помощи в починке MFT. Имеется также скан файл от R-studio. При необходимости могу предоставить. Smart снят с нужного винта. О проблемных -я в курсе-они из восстановленных.
http://imageshack.com/a/img923/1184/efJjt8.jpg
http://imageshack.com/a/img921/2049/8NvytH.jpg
http://imageshack.com/a/img921/2992/CBN9r3.jpg
https://cloud.mail.ru/public/Exro/kNq7D1i7y
полный скан выполняется [/more] [/more]
Началось все со спонтанных ошибок чтения при заполнении диска больше, чем на 60-65% - перезагрузка, CHKDSK-исправлено. Проверка Data Lifeguard Diagnostic for Windows по смарт-норм, быстрая-норм, расширенная-выявила несколько логических нестыковок-исправила. Перезагрузка, перепроверка-все норм. Диск использовался как файлохранилище, резервное хранилище данных и резервных образов системного раздела, а также для файлообмена. Температура под нагрузкой по данным из AIDA x64 выше 39 C не поднималась. Поутихло все примерно месяца на полтора, затем снова-ошибка чтения при операции чтения-записи, перезагрузка, CHKDSK. Проверил Викторией - линейный тест чтения прямой и обратный-предупреждений не выявил. Полностью перенести всю информацию не смог-не хватило свободного объема. Начал "разгружать" диск от помойки. Появились orphaned файлы при очередной загрузке системы. В итоге CHKDSK выявил проблему с MFT. Устранил, до следующей загрузки. В очередной раз проверившись при старте системы CHKDSK не смог собрать MFT. Test disk обнаружил записи, но после восстановления ситуация осталась той же. R-studio обнаружила раздел. Директории на местах, но считать их без восстановления невозможно. Восстановлением из-под R-studio не могу воспользоваться-дефицит свободного пространства для рекавери. Прошу помощи в починке MFT. Имеется также скан файл от R-studio. При необходимости могу предоставить. Smart снят с нужного винта. О проблемных -я в курсе-они из восстановленных.
http://imageshack.com/a/img923/1184/efJjt8.jpg
http://imageshack.com/a/img921/2049/8NvytH.jpg
http://imageshack.com/a/img921/2992/CBN9r3.jpg
https://cloud.mail.ru/public/Exro/kNq7D1i7y
полный скан выполняется [/more] [/more]
Ironjaw
В шапке темы http://forum.ru-board.com/topic.cgi?forum=62&topic=20390&start=3260#lt написано как делать дамп секторов.
То, что ты выложил - не то.
Кстати, в новых скриншотах видно имя тома (раньше не было), что свидетельствует о том, что 3-я запись читается.
В шапке темы http://forum.ru-board.com/topic.cgi?forum=62&topic=20390&start=3260#lt написано как делать дамп секторов.
То, что ты выложил - не то.
Кстати, в новых скриншотах видно имя тома (раньше не было), что свидетельствует о том, что 3-я запись читается.
Ironjaw
786432*8+2048=6293504
Можешь сразу сделать и дамп секторов 2048+50.
И ещё выложи лог поиска на текущий момент.
786432*8+2048=6293504
Можешь сразу сделать и дамп секторов 2048+50.
И ещё выложи лог поиска на текущий момент.
Вечер добрый, нужна помощь!
Выполнял объединение разделов жесткого диска Акронисом.
И в этот момент случилась неприятная ситуация, пропал свет) бесперебойника конечно же нет.
При включении ПК обнаружил, что Диск пропал!
В управлении дисками (утилита Windows) обнаружил, что пропала файловая система диска!
Я попробовал сжать диск (Сжать том), чтобы разбить обратно и восстановить файловую систему,
однако диск видится, но он пустой!!!
Вместо реального размера 750гб диск стал 1.26тб, (+якобы с моими файлами), но пустой!
Как быть? как вернуть нужные файлы?
http://pixs.ru/showimage/3jpg_1837202_21072573.jpg
http://pixs.ru/showimage/4jpg_8611406_21072582.jpg
Скрины с DMDE и CrystalDiskInfo прилагаю
Выполнял объединение разделов жесткого диска Акронисом.
И в этот момент случилась неприятная ситуация, пропал свет) бесперебойника конечно же нет.
При включении ПК обнаружил, что Диск пропал!
В управлении дисками (утилита Windows) обнаружил, что пропала файловая система диска!
Я попробовал сжать диск (Сжать том), чтобы разбить обратно и восстановить файловую систему,
однако диск видится, но он пустой!!!
Вместо реального размера 750гб диск стал 1.26тб, (+якобы с моими файлами), но пустой!
Как быть? как вернуть нужные файлы?
http://pixs.ru/showimage/3jpg_1837202_21072573.jpg
http://pixs.ru/showimage/4jpg_8611406_21072582.jpg
Скрины с DMDE и CrystalDiskInfo прилагаю
Ironjaw
Три начальные записи прописаны шаблоном FFFF. Не знаю что и предполагать в качестве обьяснения такого явления.
Соотвественно, ранлиста MFT нет. В логе поиска есть несколько фрагментов (правда у второго есть дубль) - можно попробовать сделать патчик.
В принципе, нельзя исключить версию что содержимое этих записей сбросилось в какое то другое место, но тогда надо смотреть кандидатов (коих немало).
Добавлено:
F1ks
Вот всякое встречалось, но чтобы сжимали том средствами винды после такого расколбаса - ни разу. Поэтому даже не знаю как в этом случае поступает винда, надеюсь что только с размерами в таблице разделов манипулирует. Вот только непонятно, если ты его сжал, то почему он всё равно 1,26тб?
Может что ещё делалось?
Три начальные записи прописаны шаблоном FFFF. Не знаю что и предполагать в качестве обьяснения такого явления.
Соотвественно, ранлиста MFT нет. В логе поиска есть несколько фрагментов (правда у второго есть дубль) - можно попробовать сделать патчик.
В принципе, нельзя исключить версию что содержимое этих записей сбросилось в какое то другое место, но тогда надо смотреть кандидатов (коих немало).
Добавлено:
F1ks
Вот всякое встречалось, но чтобы сжимали том средствами винды после такого расколбаса - ни разу. Поэтому даже не знаю как в этом случае поступает винда, надеюсь что только с размерами в таблице разделов манипулирует. Вот только непонятно, если ты его сжал, то почему он всё равно 1,26тб?
Может что ещё делалось?
temp9285
Есть предположение насчет шаблона-во время старта скана Викой самый первый сектор показался оранжевым и был заремаплен-не пойму правда почему-возможно хард не отдуплил старт теста и выдал большую задержку по чтению
Есть предположение насчет шаблона-во время старта скана Викой самый первый сектор показался оранжевым и был заремаплен-не пойму правда почему-возможно хард не отдуплил старт теста и выдал большую задержку по чтению
temp9285
никаких больше действий.
пробовал Рекувой делать поиск файлов. Находит, но представляю какая будет каша если этот процесс восстановления сделать
никаких больше действий.
пробовал Рекувой делать поиск файлов. Находит, но представляю какая будет каша если этот процесс восстановления сделать
F1ks
Ну может не ты, например чекдиск запустился и пофиксил "ошибки".
В любом случае, забери у раздела букву, чтобы винда не работала с ним.
Запусти в DMDE Полное сканирование на участке этого раздела, сохрани лог и выложи его.
Смотри что в найденном, пробуй восстанавливать и обязательно проверяй целостность.
Про кашу нужно было думать запуская акронис.
Ну может не ты, например чекдиск запустился и пофиксил "ошибки".
В любом случае, забери у раздела букву, чтобы винда не работала с ним.
Запусти в DMDE Полное сканирование на участке этого раздела, сохрани лог и выложи его.
Смотри что в найденном, пробуй восстанавливать и обязательно проверяй целостность.
Про кашу нужно было думать запуская акронис.
Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354
Предыдущая тема: Проблема HDD с востновлениям информациии
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.