Ru-Board.club
← Вернуться в раздел «Магнитные носители информации»

» Восстановление разделов и информации на HDD (часть 8)

Автор: igor_me_v2
Дата сообщения: 15.09.2016 01:50

Цитата:
База 1С, которую надо восстановить это сжатый rar-файл по сети с машины бухгалтера, и их довольно много, бекап ведется каждую ночь. Почему-то бухгалтерия просит иметь бекапы за несколько месяцев.

Дык у нас например храняться почти ежедневные копии за 3 года ! Было пару случаев, когда меня просили прицепить копии более годовой давности. Кстати, это оффтоп, но меня посетила мысль, что возможно копии 1С нужно делать так много и так часто потому что... правильно, есть такой расплодившийся сейчас подвид программеров, как "программисты 1С". Они там в рабочих (!) базах чё-то всё ковыряют, а потом иногда через время выскакивают их косяки, приходится откатываться
Mkun

Цитата:
А вот .avi .mkv восстановились корректно, не все конечно.

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

Добавлено:
temp9285

Цитата:
PS. Надеюсь на обьективность и на то, что в случае чего будут показаны настройки при которых достигнут результат. Особенно интересно узнать о результате некогда расхваленной GDB.

А как продемонстрировать результат, и какой он должен быть?
Прогнал GDB.
На 2-м образе тектовый файл читается, вместо удалённых шаблонов появилось два "удалённых" файла FTMP000S.331
На 3-м образе тектовый файл найден и читается. На 4-м - найден, но при просмотре внутри мусор и сигнатура PK.
На 5-м - в текстовом нули.
Если надо скриншоты по всем этапам - завтра сделать могу, сейчас поздно, ушёл спать
Автор: temp9285
Дата сообщения: 15.09.2016 02:37
ZSZ
У каждой программы свои алгоритмы. И вполне понятно что они могут выдавать различный результат, который может зависеть от конкретной ситуации. Photorec изначально делалась для восстановления фоток (на что как бы намекает её название) и я не могу это доказать но есть мнение, что у неё есть какие то уникальные алгоритмы. К тому же, в опциях можно выставить режим сохранения повреждённых файлов; которые потом можно попробовать восстановить программно или вручную.
И подобное мнение о возможностях программы здесь высказывал один участник, который "увлечён" ручной сборкой порушенных файлов, которому я могу верить.
В любом случае, если данные важны, и они не восстановлены программой ХХХ, то надо пробовать все возможные остальные.

Что касается твоего случая - он является более тяжёлым вариантом Mkun-овского. Насколько понимаю, у него была всего лишь перезапись, причём относительно не очень большого обьёма. Но самое главное - более на разделе ничего не делалось. И в случае, если очистить раздел от новых записей, результат может отличаться. В твоём случае работала винда, соответственно было много перезаписей, которые невозможно отследить (временные файлы, точки восстановления и т.п.). Но всё равно надо использовать любую возможность. Буквально недавно был достаточно интересный (для меня) случай с винтом одного знакомого. [more=тыц]У него возникли проблемы со свободным местом, и при анализе выявились достаточно прикольные моменты (папки с мегаразмерами или с отрицательными обьёмами) и т.п. Но попутно выяснилось что есть и сбойные сектора, часть из которых попала и в фото. И так получилось что буквально перед этим, с фотика были удалены все старые фотки а потом ещё и пофоткали немного новых. Так что восстановление шло из двух источников, в том числе использовал "сшивку" рабочих фрагментов. В ходе всех этих восстановлений было замечено, что при сигнатурном поиске (кстати photorec-ом в том числе) одни и те же фотки имели меньший размер. Выяснилось что фотоаппарат делает снимок, в котором по сути два (второй меньшего размера) и второй расположен в хвосте файла. При этом начало второго "блока" смещено от начала сектора, поэтому не находилось прогами и восстанавливался лишь первый. Так вот несколько сильно битых фоток получилось "воскресить" как раз этими вторыми. Да, разрешение меньше, но всё равно достаточное.
Чтобы было нагляднее - одна из таких фоток http://rgho.st/private/82tjnbjtn/d3bd0724edf6b42e974514babb0fe7cb
[/more]

Добавлено:
igor_me_v2

Цитата:
А как продемонстрировать результат, и какой он должен быть?

Да как удобно, главное чтобы было понятно что восстановилось. Интересует факт восстановления png файла (*) из образов 3-5, а также zip-архива из 4-го дампа (в R-studio не нашёлся).
(*) В GDB таковой не получилось восстановить.
Автор: Mkun
Дата сообщения: 15.09.2016 16:37
temp9285
Собственно лог
http://my-files.ru/qedvfl

Цитата:
Кстати, при их создании использовалась функция добавления информации для восстановления

Нет не ставилась, видимо зря.

tomset

Цитата:
А вот 90% логических случаев, это чисто разгильдяйство пользователей, как и в данном случае.

Верно

Цитата:
Важные копии хранить в одном экземпляре со всяким мусором, это уж явно говорит о полном разгильдяйстве в конторе.

Верно 2

igor_me_v2

Цитата:
Дык у нас например храняться почти ежедневные копии за 3 года ! Было пару случаев, когда меня просили прицепить копии более годовой давности.

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


Автор: temp9285
Дата сообщения: 15.09.2016 21:04
Mkun
Всё как и было раньше.
Можно попробовать поискать копию бутсектора прежнего раздела или проанализировать имеющиеся в списке 0-вые записи (*), но толку от этого практически никакого - нет самих записей.
(*) Можно для успокоения посмотреть их и карту кластеров нынешнего тома чтобы понять что сейчас располагается в местах записей MFT (или типичных местах её расположения). Если интересно - напишу как это сделать.
Автор: igor_me_v2
Дата сообщения: 16.09.2016 00:35
temp9285

Цитата:
Да как удобно


Цитата:
Интересует факт восстановления png файла (*) из образов 3-5, а также zip-архива из 4-го дампа (в R-studio не нашёлся).

Вон оно как. Тогда расклад такой. PNG файл GetData Back for NTFS v 4.00 не нашла ни в каком виде (а должна была? Там какие фрагменты, начало файла?)
Насчёт zip. Ну в виде именно zip не нашла. Нашла как txt. Если руками сменить расширение - архив открывается. Показать скриншоты?
ЗЫ Вообще такая ситуация, как с этим zip - очень специфична. Я правильно понял: в MFT запись о txt, а содержимое из zip??? Такое на автомате наверное может распознать или прога, которая сверяет содержимое даже для "целых файлов", найденных по MFT. Либо в режиме RAW-поиска при этом чтобы в проге был отключен поиск по MFT собственно. В GDB - вроде нельзя jnrk.xbnm. А вот например в Easeus Data Recovery Wizard вроде можно, но она не понимает произвольный формат образа к сожалению, только свой... Такие дела.
Автор: temp9285
Дата сообщения: 16.09.2016 01:51
igor_me_v2

Цитата:
Я правильно понял: в MFT запись о txt, а содержимое из zip???

Да.

Цитата:
Либо в режиме RAW-поиска при этом чтобы в проге был отключен поиск по MFT собственно

В R-studio такое можно отключить - тем не менее и она не нашла в сигнатурном поиске.
Опять же - "отключить" можно банально затерев запись в MFT

Вообще, тест делался достаточно спонтанно, поэтому получилось так, хотя можно будет и исправить ситуацию. Основным критерием был именно сигнатурный поиск. Причём не просто целого файла, а с элементами вкрапления новых данных.
Png файл начинается на 3 сектора раньше текстового и продолжается за ним.
Этот тип файлов был выбран не случайно, т.к. я знал что таковой (в более ранних моих тестах) сигнатурно GDB не находила, а у Р-студио вообще были приколы типа восстановление файлов размеров больше размера раздела - но это было в какой то версии 7.хх.
Что касается zip-а. Идея использования архива вместо текстового файла возникал по одной причине, о которой я намекал раньше. Смысл в том, чтобы была видна разница в алгоритме поиска.
При сигнатурке есть разные. Например, если известен размер файла то и вычитывается такой обьём данных, начиная с найденного начала. Естественно, что в этом случае между началом и концом может вклиниться "мусор" и такой вариант можно наблюдать в образе 3 (хотя я не в курсе - есть ли данные о размере png-файла в его заголовке). Но здесь очень показателен тип "мусора", и именно для показания этого и был записан zip вместо текста. Текстовый файл не имеет сигнатур и его поэтому он не воспринимается за "мусор".
А вот архив имеет и начальную и конечную сигнатуру и очень хорошо вычисляется. В таком случае, вполне очевидно, что если есть начало одного типа файла, затем полностью другой тип файла, затем продолжение первого, то очевидно что нет смысла вытягивать первый файл с содержимым второго. Собственно это очень наглядно видно в сигнатурном поиске DMDE. Из образа 3 извлекается "большой" png-файл (как и в R-studio и Photorec) А из в 4-го уже всё по другому:
- DMDE извлекает начальную часть png и полностью zip
- Photorec находит только zip, не считая нужным извлекать начало png
- R-studio восстанавливает только "большой" png, zip не находит вообще.
Хотелось бы отметить что если даже файл не целый, то начальная часть может содержать очень большой массив данных и восстановление таких вот "коцек" является правильным. И такой подход показала DMDE, чего нельзя сказать о Photorec. А R-studio вообще не заметила целёхонький архив.
И всё это наглядно показывает что при идентичном разрушении результаты разняться, потому как и алгоритмы, а главное подход разный.

Цитата:
в Easeus Data Recovery Wizard вроде можно, но она не понимает произвольный формат образа к сожалению, только свой...

В смысле? Я дал простую посекторку. Она не открывает такие, или ей дсотаточно просто дать файл с другим расширением? В любом случае, если это не позволяет программе заниматься востановлением. то грош ей цена.
Автор: ZSZ
Дата сообщения: 16.09.2016 02:24
igor_me_v2

Цитата:
Тогда расклад такой. PNG файл GetData Back for NTFS v 4.00 не нашла ни в каком виде (а должна была?


Там картинка от менеджера дисков.

Я начал, и пока забросил, (много времени надо), чтобы не забыть, вот предварительные результаты:

temp9285

Цитата:
Интересует факт восстановления png файла (*) из образов 3-5, а также zip-архива из 4-го дампа (в R-studio не нашёлся).


Пока только мельком.
PNG файл из 3-го образа, настройки на максимум:

R-Studio. Только начало png, остальное битое.
Active@File Recovery. Нет результата.
Active@Undelete. Только начало png, остальное битое.
Easy Recovery. Нет результата.
Get Data Back for NTFS. Нет результата.
PhotoRec. Нет опции "открыть образ".
R.Saver. Нет результата.
Recuva. Нет опции "открыть образ".


Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354

Предыдущая тема: Проблема HDD с востновлениям информациии


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.