Форум 3DNews
Вернуться   Форум 3DNews > Железо > Носители информации > Восстановление информации

Ответ Создать новую тему
Опции темы Опции просмотра
Непрочитано 12.02.2020, 20:50   [включить плавающее окно]   #1
Ver wolf
Мужской Новенький
Автор темы
 
Регистрация: 12.02.2020
Восстановление ФС на внешнем HDD

Всем привет!
Случилась беда.В Victoria сканировал диск в режиме write, но по запаре выбрал диск с данными. Выключил быстро, думаю ~0,1-0,2% прошло.
Диск 4Tb WD внешний, GPT, раздел был NTFS.
В DMDE такая картина. Восстановил раздел который по названию был, но файлов нет. Проблема в том, что очень большая вложенность была по папкам/файлам. Был 1 раздел на весь диск. Как его восстановить?
Есть такой же диск, в нём также 1 раздел, NTFS.
Соответственно на скринах:
good - живой диск с разделом

bad - испорченный диск с разделами


Дамп DMDE

Скрин раздела My_Data2


При открытии тома My_Data2 в DMDE есть такая ошибка


Дамп DMDE (2046 + 12 секторов)
Ver wolf вне форума  
Ответить с цитированием
Непрочитано 12.02.2020, 21:56   [включить плавающее окно]   #2
Ver wolf
Мужской Новенький
Автор темы
 
Регистрация: 12.02.2020
Данные по разделам после полного сканирования в DMDE:

Ver wolf вне форума  
Ответить с цитированием
Непрочитано 13.02.2020, 02:52   [включить плавающее окно]   #3
9285
Мужской Умудрённый
 
Регистрация: 08.02.2019
Ситуация достаточно неприятная, и она была "спроектирована" давно, когда использовался какой то сторонний менеджер дисков для создания раздела.
Сейчас не скажу точно его название, а нести напраслину на другие программы не хочется. Собственно он располагает MFT в самом начале диска, причем целиком, а не как не к ночи упомянутый акронис, который хоть и располагает в том же третьем кластере, но там только начальные записи. Собственно это и привело к тому, что накрыло, минимум, первый фрагмент MFT. Здесь ты не выложил лог сканирования, но он есть в другом месте. И по логу видно что затёрлось более 204920 записей - прям как сговорились с автором соседней темы Вот если бы форматнул виндой, то был бы "задел" в 3 гигабайта.
В дампе виден ожидаемый шаблон записываемый викторией (выделен синим). Это позволяет найти сектор докуда успела она заполнить сектора. Можешь перейти в сектор типа 100000 и посмотреть есть ли там шаблон в начале сектора.
Если есть, перейди куда подальше. Когда шаблона не будет, запусти поиск по содержимому строки и заполни поля формы как на скриншоте (зелёные). То есть, искать LBA в обратном направлении, со смещением 0 байт. И смотри что найдёт. Там где увидишь первый шаблон - это и есть крайний сектор.
Тебя не должно сбивать с толку что в самом начале тома есть бутсектор (выделен красным) и четыре начальные записи MFT - это уже винда восстановила из копий.
Миниатюры
Нажмите на изображение для увеличения
Название: m_ppc.PNG
Просмотров: 62
Размер:	21.4 Кб
ID:	56793   Нажмите на изображение для увеличения
Название: m_lba.PNG
Просмотров: 67
Размер:	50.4 Кб
ID:	56794  
9285 вне форума  
Ответить с цитированием
Непрочитано 13.02.2020, 03:03   [включить плавающее окно]   #4
9285
Мужской Умудрённый
 
Регистрация: 08.02.2019
Что делать в данной ситуации?
То же, что и в упомянутой Проблемы с хардом (новое)
Открывать том в DMDE, делать виртуальную реконструкцию и восстанавливать инфу, данные которой были в выживших записях.
Конечно же потери будут,будут безымянные папки, но ничего другого не будет.
Всё остальное искать в результатах сигнатурного поиска и надеяться что оно было не фрагментировано.
9285 вне форума  
Ответить с цитированием
Непрочитано 13.02.2020, 07:26   [включить плавающее окно]   #5
Ver wolf
Мужской Новенький
Автор темы
 
Регистрация: 12.02.2020
Поправленная ссылка на DMDE:
https://drive.google.com/file/d/1aUN...ew?usp=sharing

Дамп сектора 2072+12:
dev3_lba2072_13.zip
Ver wolf вне форума  
Ответить с цитированием
Непрочитано 13.02.2020, 09:00   [включить плавающее окно]   #6
9285
Мужской Умудрённый
 
Регистрация: 08.02.2019
Что там насчёт определения конца перезаписи?
Это для понимания масштабов затирания, хотя в большей степени для понимания того что:
- спасло бы тебя если бы диск форматировался виндой.
- сколько бы ещё записей умерло если бы MFT не была бы фрагментирована. А сейчас, дамп подтвердил написанное выше - перезаписался первый фрагмент.
Миниатюры
Нажмите на изображение для увеличения
Название: m_0rec.PNG
Просмотров: 51
Размер:	13.4 Кб
ID:	56796  
9285 вне форума  
Ответить с цитированием
Непрочитано 13.02.2020, 15:04   [включить плавающее окно]   #7
9285
Мужской Умудрённый
 
Регистрация: 08.02.2019
Exclamation

Небольшой размышлязм по поводу случившегося и не только.
СПОЙЛЕР »
В практике форумных случаев бывали разные, при которых производилось уничтожение данных в начале диска (тома).
К ним относится ситуация подобно твоей а также некоторые другие, которые можно разделить на две основные подгруппы.
1. Перезапись идёт последовательно от начала к концу.
Как в твоём случае - запись викторией или чем то подобным.
Полный формат тома средствами висты и более новых. Или запуск в дискпарте команды clean с ключём all
В случае своевременного прекращения действия, достаточно легко определить обьём повреждений.
2. Перезапись не очень предсказуема.
Например, при записи загрузочной флэшки, по ошибке выбрали не тот (внешний) диск. В этом случае всё зависит от алгоритма используемого ПО - то есть пишет ли оно последовательно (как в первом варианте), или может писать хаотично, вплоть до обратной записи. В этом случае определить точно степень повреждения не всегда возможно.
К этой категории отчасти можно отнести и простой формат виндой.
Ну и раз вспомнили микрософт, то как же не вспомнить их запись дистрибутивного носителя винды. На диске может быть несколько разделов и пользователь как бы указывает только первый, но удаляются все разделы и создаётся один новый - обычно на 32 гига, при том, что дистрибутив всего то 8.
Ну и, конечно же, в эту категорию попадает и заворот данных, записываемых далее 2ТБ. Вот здесь хаотичность вообще непредсказуемая.

В этот момент "на сцене" могут появиться те, кто напишет "сам виноват", "надо иметь бэкап" и т.п. Да, они правы, но не всё в жизни бывает просто и лишь ЧБ. Поэтому и рассматривает множественные оттенки цвета.
Конечно же, разделение диска на тома может частично уменьшить потери - пострадает лишь начальный раздел (*). Но если так сильно не хочется делить диск на крупные части, то может быть создать небольшой буферный раздел в начале - на те же 32-50 гигов, которые защитят от большей части из приведённых случаев?

(*)В случае записи бутявки через расскатывание образа, не исключён вариант данные образа могут быть "равномерно размазаны" по всей поляне диска.
А в случае заворота данных повреждения могут залететь и в более дальние области. Тут есть зависимость от того куда пишется (каков обьём более 2ТБ).
9285 вне форума  
Ответить с цитированием
Непрочитано 13.02.2020, 17:44   [включить плавающее окно]   #8
Smirnoff
Мужской Модератор
 
Аватар для Smirnoff
 
Регистрация: 30.12.2004
Адрес: Новосибирск
Цитата (9285) »
может быть создать небольшой буферный раздел в начале - на те же 32-50 гигов, которые защитят от большей части из приведённых случаев?
А вот возражу: коль скоро пользователь окажется настолько продвинутым, что сообразит создать такой раздел - так он и не перепутает накопители при запуске Victoria, и не создаст "флешку" на рабочем накопителе, и уж тем более не станет diskpart со всякими ключами запускать не подумавши предварительно...
__________________
С уважением,
Олег Р. Смирнов
Smirnoff вне форума  
Конфигурация ПК
Ответить с цитированием
Непрочитано 13.02.2020, 21:21   [включить плавающее окно]   #9
Ver wolf
Мужской Новенький
Автор темы
 
Регистрация: 12.02.2020
Цитата (9285) »
Что там насчёт определения конца перезаписи?
Это для понимания масштабов затирания, хотя в большей степени для понимания того что:
- спасло бы тебя если бы диск форматировался виндой.
- сколько бы ещё записей умерло если бы MFT не была бы фрагментирована. А сейчас, дамп подтвердил написанное выше - перезаписался первый фрагмент.
Собственно вот этот крайний сектор:


Честно не помню где именно разбивал раздел, но возможно и не через стандартные средства или Acronis. Может через AIOMEI.

То, что ситуация печальная сильно удручает.
На диск изначально записывались не особо нужные видео/iso образы. Примерно 50% диска.
Потом туда была перекинута инфа с 2 Tb HDD. И вот эти 2 Tb очень хотелось бы вернуть.

Есть какие-то шансы на восстановление? Или лучше обратиться в специализированную фирму и доверить им(предварительно сняв образ с помощью ddrescue)?

В R-Studio такая картина после сканирования:

Ver wolf вне форума  
Ответить с цитированием
Непрочитано 13.02.2020, 21:49   [включить плавающее окно]   #10
9285
Мужской Умудрённый
 
Регистрация: 08.02.2019
Smirnoff
Во первых, я как раз таки и советую не провдинутым пользователям создать и обьясняю для чего.
А в нулевых - что здесь делает супермен?
Потому как лишь они никогда не ошибаются и делают всё правильно. Хотя в реалии и продвинутые пользователи ошибаются, и нередко очень жестоко.
В курсе кто больше погибает от удара электричества (в смысле какой разряд у таковых (был)) ?


Добавлено через 17 минут
Ver wolf
Цитата
Собственно вот этот крайний сектор
Вот и подтверждение того, что написал ранее.
Если бы диск размечался виндой, то она бы создала в начале служебный раздел, размером что то около 264192 сектора.
794624-264192=530432 сектора - примерно 250 мегабайт.
Конечно же, даже в случае формата тома виндой, нельзя исключать что в начале диска мог бы оказаться какой то фрагмент MFT, но уж точно не начальный и не такого размера.

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

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

Цитата
На диск изначально записывались не особо нужные видео/iso образы. Примерно 50% диска.
Потом туда была перекинута инфа с 2 Tb HDD. И вот эти 2 Tb очень хотелось бы вернуть.
А вот тут многое зависит от числа файлов и удалялось ли старое. При записи нового файла ей выделяется первая свободная запись (с минимальным номером).
То есть, если ранее было записано чуть меньше 205000 записей, то все новые будут целы, и если что то пострадает, то только то, что попало в зону перезаписанных секторов. Если же меньше или после что то удалялось записано, то ситуация уже не такая радужная и надеятся можно лишь на сигнатурку.

Последний раз редактировалось 9285; 13.02.2020 в 22:07.
9285 вне форума  
Ответить с цитированием
Непрочитано 13.02.2020, 22:32   [включить плавающее окно]   #11
Ver wolf
Мужской Новенький
Автор темы
 
Регистрация: 12.02.2020
Цитата
Что касается р-студио - в части восстановления по файловой системе ситуация настолько проста что нет особой разницы какой программой пользоваться. Конечно же не рассматриваются бестолковые программы.
Другое дело - восстановления по сигнатурам. В этой части разные программы могут дать разные результаты, поэтому надо пользоваться разными.
А можете что-то посоветовать из не бестолковых программ по восстановлению?
Пока планирую DMDE + R-Studio, ещё пройтись R.Saver. Сейчас жду отдельный диск под восстановление (в последующем для backup).

Но наверное всё таки существуют более продвинутые софтины для восстановления, которые по цене не для конечного потребителя и используются в СЦ. Вот хотелось бы и понять, стоит ли ограничиться "домашним" восстановлением или всё же есть шанс увеличить количество восстановленного путём обращения как раз таки в СЦ. Просто не имел опыта обращения к ним.
Ver wolf вне форума  
Ответить с цитированием
Непрочитано 13.02.2020, 22:59   [включить плавающее окно]   #12
9285
Мужской Умудрённый
 
Регистрация: 08.02.2019
Оххх, тут можно целый трактат написать по поводу лишь части твоего вопроса.
И чтобы всё это понять надо хотя бы немного понимать как всё это устроено, и насколько это сложно и инвариантно.
Из спецсофтин можно вспомнить Data Extractor, входящий в комплекс PC-3000, который в основном и используют специализированные фирмы по восстановлению данных (DR). И, насколько понимаю, одной из фишек оного является возможность работы с исключающими областями (зонами). Применительно к твоему случаю, это означает что всё, что нормально восстановилось, исключается из зоны поиска (считается что этих данных нет), что позволяет найти сигнатурно то же файл что был раньше, но уже без мусора и не только первый фрагмент.
В обычных СЦ обычно пользуют всё то ПО, что доступно любому пользователю. Вполне возможно что есть ПО собственной разработки, которое и используется в тех же DR, но оно самописное, нередко под спецзадачи, и не для остальных.

PS. Если будешь использовать R/Saver, то лучше использовать старую версию - это не только моё мнение.
9285 вне форума  
Ответить с цитированием
Непрочитано 14.02.2020, 12:26   [включить плавающее окно]   #13
Smirnoff
Мужской Модератор
 
Аватар для Smirnoff
 
Регистрация: 30.12.2004
Адрес: Новосибирск
Цитата (9285) »
В курсе кто больше погибает от удара электричества (в смысле какой разряд у таковых (был)) ?
У меня была IV группа допуска до 1000 Вольт (с правом выписывать наряд-допуск) - но я жив-таки...
__________________
С уважением,
Олег Р. Смирнов
Smirnoff вне форума  
Конфигурация ПК
Ответить с цитированием
Непрочитано 14.02.2020, 12:58   [включить плавающее окно]   #14
garniv
Мужской Модератор
 
Аватар для garniv
 
Регистрация: 29.06.2004
Цитата (Ver wolf) »
Но наверное всё таки существуют более продвинутые софтины для восстановления
Наверняка есть, например https://www.youtube.com/watch?v=QX7y4Var_fQ пытается
И первое что попалось из научных исследований: https://www.sciencedirect.com/scienc...42287616300512
Еще есть методы статистиического анализа как например в JPEGfix, позволяющие примерно понять какого типа данные
__________________
Хочешь помочь новичку — делай вместе с ним. Хочешь помочь старику — делай вместо него. Хочешь помочь мастеру — отойди и не мешай. А хочешь помочь Таргитаю — сам Таргитай.

Последний раз редактировалось garniv; 14.02.2020 в 13:12.
garniv вне форума  
Конфигурация ПК
Ответить с цитированием
Непрочитано 14.02.2020, 20:04   [включить плавающее окно]   #15
9285
Мужской Умудрённый
 
Регистрация: 08.02.2019
garnivМного что есть, но только надо понимать что всё это индивидуально и при определённых условиях.
Тот же JPEGfix используется для файла, который точно позиционируется как изображение, но повреждён в силу тех или иных обстоятельств.
Carving тоже имеет разные ограничения, но основное - обьём исследуемого пространства. Одно дело откарвить 64 мега, совсем другое терабайт. Да и сами файлы бывают разные. Как то немного поковырял это дело. Вот png-файлы имеют очень чёткую структуру и chunk-и чётко соответствуют структуре данных (*). Опять же, зависит и от размера chunk - одно дело если очередной имеет размер в пределах кластера. В этом случае последовательно перебираются кластера по одному, более того можно проверять только кластера, в которых в известном смещении находится новый чанк. А теперь представь что следующий чанк имеет размер 100 кластеров. Концевой можно отобрать как описано перед этим, а вот остальные 99, представь какое число комбинаций. а теперь ещё наложить на то, что кластеров не 100 и надо только перебирать их последовательность, а 100500 тысяч. Мало того, потом ещё выяснится что один из фрагметнов пострадал из за сбойного сектора (AF). Опять же, программа должна уметь исключать из перебора участки, которые однозначно принадлежат каким то файлам.
(*) Вот с jpeg-ами такой чёткости нет.

Smirnoff
Речь не о суперменах, а тех, кто имел высокий разряд (группу допуска).
9285 вне форума  
Ответить с цитированием
Непрочитано 15.02.2020, 07:40   [включить плавающее окно]   #16
9285
Мужской Умудрённый
 
Регистрация: 08.02.2019
Exclamation

Кстати, могу предложить провести небольшой эксперимент по сигнатурному поиску.
В приложенных архивах смоделированы две типичные ситуации:

ins8.bin - в файл-картинку, вставлен другой файл. Это имитирует ситуацию фрагментации исходного файла - по сути вариант того, что может быть у автора темы

over8.bin - те же файлы, только второй уже не вставлен а записан поверх. Это имитирует перезапись, формат - это уже ситуация как у автора другой темы, который поставил винду поверх прежних данных.

В принципе, не так уж сложно определить что и куда вставлено и вручную восстановить исходный файл. Но на практике ситуация сложнее; поэтому предлагаю использовать любое ПО (настройки оного) и посмотреть результат.
Вложения
Тип файла: zip ins8.zip (229.7 Кб, 28 просмотров)
Тип файла: zip over8.zip (221.7 Кб, 29 просмотров)
9285 вне форума  
Ответить с цитированием
Непрочитано 17.02.2020, 15:41   [включить плавающее окно]   #17
9285
Мужской Умудрённый
 
Регистрация: 08.02.2019
Что то 8 "просмотров" архивов а результатов нет.
А между тем результаты достаточно прикольные.
9285 вне форума  
Ответить с цитированием
Непрочитано 20.02.2020, 23:08   [включить плавающее окно]   #18
9285
Мужской Умудрённый
 
Регистрация: 08.02.2019
Своеобразный отчёт.
Для начала оригинальные файлы - основной и вставленный "мусорный".
Мусорный файл вставлен (или перезаписан) в LBA8.
Используемые программы - DMDE и photorec (*).
В обоих из них сканировались предоставленные дампы; в случае photorec использовались разные настройки сканирования.
Миниатюры
Нажмите на изображение для увеличения
Название: original.png
Просмотров: 43
Размер:	223.7 Кб
ID:	56857   Нажмите на изображение для увеличения
Название: musor.jpg
Просмотров: 43
Размер:	8.0 Кб
ID:	56858  
9285 вне форума  
Ответить с цитированием
Непрочитано 20.02.2020, 23:17   [включить плавающее окно]   #19
9285
Мужской Умудрённый
 
Регистрация: 08.02.2019
DMDE.
В обоих из образцов был найден начальный фрагмент основного файла и весь мусорный.
Смоделировав ситуацию когда известно что в фале присутствует мусор сделал зачистку оного - то есть были обнулены 16 секторв начиная с 8-го.
В результате получены битые png-ки размером с сам дамп, но в них уже видно что то.

PS. Непонятно почему, но у меня, при просмотре из браузера, 200 килобайтные файлы показывают только то, что и в f0.png. Сохранённые же на диск отображаются как есть.
Миниатюры
Нажмите на изображение для увеличения
Название: f8.jpeg
Просмотров: 40
Размер:	7.9 Кб
ID:	56863  
Изображения
Тип файла: png f0.png (4.0 Кб, 40 просмотров)
Тип файла: png ins_zero.png (231.7 Кб, 46 просмотров)
Тип файла: png over_zero.png (223.7 Кб, 41 просмотров)

Последний раз редактировалось 9285; 20.02.2020 в 23:41.
9285 вне форума  
Ответить с цитированием
Непрочитано 20.02.2020, 23:32   [включить плавающее окно]   #20
9285
Мужской Умудрённый
 
Регистрация: 08.02.2019
Photorec
Вот здесь использовалась та же метода, но комбинаций настроек настолько много что описывать все немного муторно. Поэтому приведу лишь самые показательные - все остальные желающие (если ещё остались) могут проверить сами.
При дефолтных настройках в образце со вставкой (как минимум) не найдено ничего. При отключении Paranoid нашлись те же что и в DMDE заголок и мусорный файл. Самый цимус случился в этом образце при включении BrutForce - файл восстановился полноценно.. То есть, программа смогла определить мусор, убрать его и "сшить" две половинки.
PS. пробовал и в R-studio сканировать, но сейчас не припомню что там было "прикольного". Возможно попозже освежу результаты.
В любом случае, тест наглядно показывает что и "разорванный" файл может восстановится, и что многое зависит от условий и настроек программ.
9285 вне форума  
Ответить с цитированием
Ответ Создать новую тему

Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 20:37. Часовой пояс GMT +3.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 2000-2017 3DNews. All Rights Reserved.
Администрация 3DNews требует соблюдения на форуме правил и законов РФ
Серверы размещены в Hostkey