LINUX.ORG.RU

ошибка в адресате для DD=запоротый NTFS

 


0

2

Собственно все просто и банально.Понадобилось из под МХ’a записать на флешку загрузочный образ. Изза ошибки в указании адресата приёмника - вместо флешки, образ был отправлен через команду DD на другое устройство, коим оказался хард 1Тб с разделом в NTFS. Соответственно ~2 Gb HDD были перезаписаны до обнаружения сего прискорбного факта. ОС файловую систему неопознает ну отсюда все вытекающие. Вопрос: как и чем попроще восстановить структуру тома из LINUX чтоб вытащить оставшуюся инфу или починить файловую систему. Хард обычный 1 Тб заполнен был примерно на 90%.

DMDE (старенький 2.0.1) инфу видит, но пофайлово восстанавливать долго, а покупать новый ради одноразового применения нехочется.

Testdisk на этом харде находит тома с разными размерами и типами ФС, как среди них найти нужную? если последний точный размер тома неизвестен?. Как вычислить какое из зеркал мфт мне нужно? Может кто посоветует несложное решение. Должен же быть простой метод починки нтфс разделов.


Восстановление NTFS раздела.

Если есть возможность сними образ с винта и проводи эксперименты с ним.

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

Не понятно куда Ты эти 2 гектара записал. ИМХО от этого будет зависеть простота успеха.

Mixa
()
Последнее исправление: Mixa (всего исправлений: 2)

затер два гига

хочет просто

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

legolegs ★★★★★
()
Ответ на: комментарий от Mixa

Не понятно куда Ты эти 2 гектара записал.

В начало, конечно.

Deleted
()

1) Виндовую FS надо восстанавливать на винде (ну или с помощью кроссплатформенной r-studio, к примеру)

2) Надо иметь диск размером с таким же объёмом, чтобы восстанавливать туда информацию.

Deleted
()
Ответ на: комментарий от Mixa

Пробовал сделать бэкап пострадавшего харда на другой хард командой типа dd if=/dev/sdb of=/dev/sdm bs=16M c с параметром noerror, где sdm полностью пустой без таблицы разделов 2тб Hdd. Тест диск там обнаруживает фат 32 разделы малых размеров и ничего более. Теоретически в hex редакторе можно посмотреть куда именно попали данные при записи (поискав по началу и концу данных записываемого образа), но что это даст? И так ясно что основная мфт повреждена. По идее команда dd передает из источника в приемник и ей без разницы что там на другом конце: жесткий флешка сидюк или другое устройство.Так как при записи получателем был указан диск целиком, а не конкретный раздел, предполагаю, что записалось в самое начало диска, а не в ближайшее незанятое место.

YO3C28
() автор топика
Ответ на: комментарий от YO3C28

винда выравнивает разделы по границе 1 MiB ( т.е. первый раздел скорее всего начинается с 2048 сектора )

С этой подсказкой testdisk скорее всего сможет обнаружить резервную копию метаданных ntfs

а вот если разделов больше 1, тогда уже грустно

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)

MFT скорее всего жива т.к. живет в центре диска.

на винте вообще сколько разделов-то было?… если один - то все просто по идее, создать таблицу разделов, и смотреть что читается…

NiTr0 ★★★★★
()

Восстанови важные данные из бекапа, делов то. А раздел заново отформатируй.

aquadon ★★★★★
()
4 апреля 2020 г.

Вобщем данные были вытащены еще в начале марта с помощью r-sudio live. Часть как и ожидалось оказалась битой ~3-5%.

YO3C28
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.