Восстановление объединенного раздела

rvklyuev · 03.02.2020, 16:00

Добрый день. Жесткий диск объемом 500 Гб имел 2 раздела которые в последующем были объединены средствами Windows 7. При попытке использования диска на другом ПК (во внешнем корпусе) всплыла ошибка с уведомлением о необходимости форматирования жесткого диска.
Пытался восстановить раздел с помощью Testdisk, ошибочно восстановил раздел 9гб, нужных разделов Testdisk не находит.
Hetman Partition Recovery находит раздел с правильным размером но все восстанавливаемые файлы не читаемые.
R Studio находит 2 раздела объемом 146 Гб, не содержащий необходимых файлов, и объемом 465, на котором находится нужная информация, но при попытке восстановления не удается восстановить примерно 35 процентов файлов.
DMDE, при построении файловой системы выдает ошибку «MTF #488740-651519», корректно восстанавливает 65 процентов файлов.
Есть ли способ спасти файлы?
Сканы DMDE и Rstudio https://yadi.sk/d/SeNOTsVdvVOT3g https://yadi.sk/d/6ABFTfvZ8eT2kg

**XaXoL** · 03.02.2020, 17:11

Я не великий знаток в этом направлениюю, но боюсь что максимум который можно выжать в данной ситуации таков:

Цитата (rvklyuev) »

объемом 465, на котором находится нужная информация, но при попытке восстановления не удается восстановить примерно 35 процентов файлов.

9285 · 03.02.2020, 20:18

Насколько знаю, винда не позволяет использовать динамические диски на внешних дисках. В случае "обычных" дисков диск определяется инородным, но его можно импортировать. А вот как реагирует винда при таком подключении не знаю, не исключено что и может предложить отформатировать. А может предложение отформатировать связано и с чем то другим - по SMART-у вроде бы нормально, хотя подобные диски встречались с периодически проявляющимися софт-бэдами. По крайней мере есть проблема с бутсектором тома - его содержимое видно на одном из скриншоте, при этом на экане Разделы отсутствует индикатор B.
Но, даже если бы с диском всё было бы идеально, и получилось бы подключить его как внутренний + импортировать; то восстановление 9-ти гигового раздела могло внести изменения в некоторые сектора в области этих 9-ти гиг.
Поэтому даже теоретический вариант восстановления массива по месту исключаем и переходим к обычному восстановлению.
Почитай Проблема с составным томом
В той теме используется другой тип тома, но основные понятия устройства LDM и его записей идентично.
Судя по описанию и логу скана DMDE понятно что речь идёт о составном томе, в котором первая часть начинается в секторе 307202048 и заканчивается где то ближе к концу диска. Вторая часть начинается в начальной зоне (физического) диска - и в ней расположена одна из частей MFT, как раз та, которая не читается при реконструкции. Собственно и надо определить размеры и начала частей и "сшить" их в DMDE используя функцию сборки массива. Эти данные можно узнать, распарсив данные записей VBLK (про это есть в указанной теме). Если не удобно использование сборки виртуального массива, то можно записать части на пустой диск - сначала первую, за ней вторую (при необходимости реконструировать бут сектор), и уже работать с таким томом.

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

Добавлено через 20 минут

XaXoL
На одном из скриншотов видно что не читается блок записей MFT 488740-651519
Собственно он и расположен во второй части составного тома. При простом восстановлении программы не считывают их, и вполне логично что не получается восстановить все данные, которые хранятся в этих записях.
Но в блоке только 25% записей. Хотя 10 процентов можно отнести на те файлы, которые восстановлены но битые - в том числе из за того что часть их данных в той самой второй части.
тут более смущает

Цитата

Hetman Partition Recovery находит раздел с правильным размером но все восстанавливаемые файлы не читаемые.

и именно в части ВСЕ. По мне так логично что те файлы, что расположены целиком в первой части, должны бы восстановится нормально. И если бы подобное было написано про рекуву, то не удивился - хитман вроде бы не такая уж и бестолковая.

rvklyuev · 04.02.2020, 18:05

В общем, похоже, что ларчик просто открывался. В RStudio создал виртуальный раздел и перетащил туда оба найденных раздела. Сейчас идет восстановление, ошибок нет. Думаю, в DMDE тоже можно было сделать что-то подобное.

9285 · 04.02.2020, 20:08

rvklyuev

Цитата

В RStudio создал виртуальный раздел и перетащил туда оба найденных раздела

Возможность работы с виртуальным массивом видел, но как то всё не доводилось проверить по хорошему. Помнится раньше не всё так "просто" было. Хотя возможно простота связана с тем, что база LDM цела. Так что, спасибо за инфу, как нибудь проверю эту возможность с разными конфигурациями - в том числе с отсутствующей базой.

Цитата

В общем, похоже, что ларчик просто открывался.

Та оно всё просто, когда знаешь и понимаешь что делать. А ещё и где спросить.

03.02.2020, 20:18	[включить плавающее окно] #3
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	Насколько знаю, винда не позволяет использовать динамические диски на внешних дисках. В случае "обычных" дисков диск определяется инородным, но его можно импортировать. А вот как реагирует винда при таком подключении не знаю, не исключено что и может предложить отформатировать. А может предложение отформатировать связано и с чем то другим - по SMART-у вроде бы нормально, хотя подобные диски встречались с периодически проявляющимися софт-бэдами. По крайней мере есть проблема с бутсектором тома - его содержимое видно на одном из скриншоте, при этом на экане Разделы отсутствует индикатор B. Но, даже если бы с диском всё было бы идеально, и получилось бы подключить его как внутренний + импортировать; то восстановление 9-ти гигового раздела могло внести изменения в некоторые сектора в области этих 9-ти гиг. Поэтому даже теоретический вариант восстановления массива по месту исключаем и переходим к обычному восстановлению. Почитай Проблема с составным томом В той теме используется другой тип тома, но основные понятия устройства LDM и его записей идентично. Судя по описанию и логу скана DMDE понятно что речь идёт о составном томе, в котором первая часть начинается в секторе 307202048 и заканчивается где то ближе к концу диска. Вторая часть начинается в начальной зоне (физического) диска - и в ней расположена одна из частей MFT, как раз та, которая не читается при реконструкции. Собственно и надо определить размеры и начала частей и "сшить" их в DMDE используя функцию сборки массива. Эти данные можно узнать, распарсив данные записей VBLK (про это есть в указанной теме). Если не удобно использование сборки виртуального массива, то можно записать части на пустой диск - сначала первую, за ней вторую (при необходимости реконструировать бут сектор), и уже работать с таким томом. PS. Кстати, вариант сборки массива может и предпочтительней в том плане что это по сути та же посекторка для обычного диска, которую используют при наличии физических проблем с диском и для подстраховки в случае когда делается восстановление по месту. Добавлено через 20 минут XaXoL На одном из скриншотов видно что не читается блок записей MFT 488740-651519 Собственно он и расположен во второй части составного тома. При простом восстановлении программы не считывают их, и вполне логично что не получается восстановить все данные, которые хранятся в этих записях. Но в блоке только 25% записей. Хотя 10 процентов можно отнести на те файлы, которые восстановлены но битые - в том числе из за того что часть их данных в той самой второй части. тут более смущает Цитата Hetman Partition Recovery находит раздел с правильным размером но все восстанавливаемые файлы не читаемые. и именно в части ВСЕ. По мне так логично что те файлы, что расположены целиком в первой части, должны бы восстановится нормально. И если бы подобное было написано про рекуву, то не удивился - хитман вроде бы не такая уж и бестолковая. Последний раз редактировалось 9285; 03.02.2020 в 20:29.

04.02.2020, 18:05	[включить плавающее окно] #4
rvklyuev Новенький Автор темы Регистрация: 31.01.2020	В общем, похоже, что ларчик просто открывался. В RStudio создал виртуальный раздел и перетащил туда оба найденных раздела. Сейчас идет восстановление, ошибок нет. Думаю, в DMDE тоже можно было сделать что-то подобное. Миниатюры

Опции темы
Версия для печати Отправить по электронной почте
Опции просмотра
Линейный вид Комбинированный вид Древовидный вид

03.02.2020, 17:11	[включить плавающее окно] #2
XaXoL Модератор Регистрация: 17.03.2004 Адрес: K-PAX	Я не великий знаток в этом направлениюю, но боюсь что максимум который можно выжать в данной ситуации таков: Цитата (rvklyuev) » объемом 465, на котором находится нужная информация, но при попытке восстановления не удается восстановить примерно 35 процентов файлов.

04.02.2020, 20:08	[включить плавающее окно] #5
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	rvklyuev Цитата В RStudio создал виртуальный раздел и перетащил туда оба найденных раздела Возможность работы с виртуальным массивом видел, но как то всё не доводилось проверить по хорошему. Помнится раньше не всё так "просто" было. Хотя возможно простота связана с тем, что база LDM цела. Так что, спасибо за инфу, как нибудь проверю эту возможность с разными конфигурациями - в том числе с отсутствующей базой. Цитата В общем, похоже, что ларчик просто открывался. Та оно всё просто, когда знаешь и понимаешь что делать. А ещё и где спросить.