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

KitePark

Цитата:

с того где раньше был диск Ф. или с того где он должен был оказаться после перемещения? Если сканировать с сектора старого расположения диска, то не будет ли дублей файлов много найдено?

В зазоре могут остаться какие то данные. Так что выбирай - они или возможные дубли.


Цитата:

Правда меня шокирует мысль сортировать такое количество файлов. Можно что то еще придумать?

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

9285
ok,
Проги думаю есть которые дубли ищут по хэшу. да?
Насчет замечания подписываюсь под каждым словом. Слишком самоуверен был и неосмотрителен. за что и поплатился.
Ладно. Какую-то огромную кучу фотографий восстановил. Теперь будет чем заняться зимними вечерами, сортируя все это по новой.

KitePark
Попробуй http://dupkiller.com/index_ru.html
Но тут есть одно но, обусловленное спецификой сигнатурного восстановления.
Один файл может сохраниться (например) размером 100 кластеров, а другой 101 - и это будут одинаковые по содержимому, но разные по контрольной сумме.

Если никуда не спешишь (по крайней мере сильно), то можно попробовать всё таки найти сдвиг и, учитывая его, попробовать восстановить с именами и иерархией, а самое главное - без "хвостов" и особенно фрагментированные файлы. Правда, в случае разрушений акронисом задачка не из простых.
Если интересно могу описать как это делается, но не сейчас - надо убегать.

KitePark

Цитата:

AnyFound Photo Recovery даст такой же результат?

Да, файлы будут восстановлены без исходных имён и структуры каталогов.

KitePark
для сортировки фото часто помогает наличие EXIF-данных.
много утилит уже написано на эту тему, начиная
- от стандартного проводника, где можно выбрать сортировку по "времени снятия снимка", "размера кадра" и "модели фотоаппарата"
- до таких как например EXIF JPEG Renamer или Namexif.

9285
да. я не тороплюсь. помоги как сможешь пожалуйста.

KitePark
Тебе важны только фотки?
И есть ли какие то целые фотки имена которых ты знаешь точно?

9285
по хорошему нужны фотки JPG, фотки PNG, видео MOV MP4 AVI, документы Word Excel PDF, несколько архивов RAR ZIP но это уже совсем не обязательно.
Но фотки самое важное и большигство из них JPG
Нашел один файл целый среди тех, что были восстановлены вместе с файловой структурой. Но там таких совсем не много. На всякий слуйчай указал весь путь по которому он лежал. И там же файлик этот же но уже восстановленный по сигнатурному поиску.
Это поможет?
http://rghost.ru/7SdMnZG8J


Добавлено:
билд акрониса кстати был 11.0.2343

Добавлено:
сейчас заметил что что файлы разных размеров, хотя это точно один и тот же файл. Странно как то это для меня

Здравствуйте! Неожиданно случилась беда. Win8.1 - пропал HDD. Нашелся на вкладке "управление дисками". Система предлагает его "инициализировать". Информация на диске крайне ценная. HDDScan говорит следующее:

ezmailer
сочувствуем) у тебя аппаратная проблема какая то с винтом. я бы наверное снял образ с диска посекторный и уже с него информацию восстанавливал бы. не известно сколько еще диск твой проживет.

ezmailer
вы это серьезно??
Maxtor DiamondMax Plus 9 6Y200P0 200GB и "Информация на диске крайне ценная" еще и под Win 8.1?!? О_о

ищите HDD clone, снимайте образ, если повезет, потом образ загружать в софт по восстановлению данных и там вычитывать. Читайте шапку темы тут.

А этого динозавра (я про Макстор) выбросить подальше, чтоб не травмировал психику неокрепших организмов.

KitePark
Начал было писать, но понял что это не так просто описать.
Нашёл написанное гуру - http://rghost.ru/6PfXfJ5My
Если что непонятно - спрашивай. хотя я всё таки напишу ещё кое что.
Ещё пообщался с dmde - он предложил воспользоваться бэта-версией http://rghost.ru/6PfXfJ5My , в которой используются новые алгоритмы, в том числе использование сигнатур.

Разность размеров файлов имеет обоснование; тем не менее файлы разные - так как начала разные.

9285
Ссылка на бету версию не верная.
Хотя наверное это и не важно. Слишком сложная для меня эта инструкция. Не осилю(
Да и бог с ним наверное. Прогнал еще раз для верности поиск по сигнатурам с помощью active file recovery. Вроде даже больше файлов нашлось. Плюс прога может восстанавливать сразу сортируя фото по папкам используя записи в свойствах файла..

Добавлено:
Нашел я другой реперный файл. Размер совпадает. Но дальше второго шага у меня мозга не хватает продвинуться

Добавлено:
Кстати active file recovery обзывает найденный файлы как раз по номеру сектора где он был найден. В моем случае это был PDF, который я точно знаю где лежал и как назывался. На битом разделе его программа нашла и обозвала found_2316963008_76172866.pdf вторая цифра это что? Просто это точно не сектор. Т.ее в этой области раздела нет битого. Он где то с 1500000000 и далее идет.

Добавлено:
Win hex нашел название файла в секторе 2336102115 со смещением 1167с2DC6CC. А чего дальше делать я не знаю.

Добавлено:
Я допер. Вторая цифра в названии это размер в байтах

KitePark
Да, со ссылкой не доглядел - http://dmde.ru/moredownload.html

Цитата:

. Плюс прога может восстанавливать сразу сортируя фото по папкам используя записи в свойствах файла..

У файла нет таких свойств - инфрмация может браться из MFT, и опосредованно из индексов.
Просто если иметь несколько различных данных анализа, в том числе и повредённых, можно всё таки собрать "пазл". Тут основное - алгоритмы поиска и профессионализм (аналитический ум) разработчиков.


Цитата:

Нашел я другой реперный файл. Размер совпадает.

Цитата:

Кстати active file recovery обзывает найденный файлы как раз по номеру сектора где он был найден.

Если ты уверен в имени файла и содержимое его, то остаётся сравнить номер сектора где он начинается и номер начала по данным из записи MFT.

Я имел ввиду что прога берет данные exif и по ним сортирует. Тут думаю mft не причем.

Звучит легко, но как это сделать, я не понял.

KitePark
Открываешь том с началом в секторе 1573091328.
Если его нет в Разделах то делается просто.
Вариант 1.
1.1 Переходишь в указанный сектор: в меню Редактор - Физические секторы
1.2. Меняешь вид на загрузочный NTFS - клавиша F7
1.3. Нажимаешь Enter, еще раз - всё, ты зашёл в том.
Вариант 2.
Запускаешь Поиск NTFS, и потом Загрузить. Выбираешь ранее сохранённый лог и в списке найденных томов выбираешь нужный.
Данный вариант имеет плюс в том, что весь том просканирован и будет больше данных; минус в том что и "мусор" будет.

Теперь найди в дереве каталогов место, где лежал реперный файл (*) и смотри в столбец Номер MFT - там номер записи (цифра до скобок).
Можешь шёлкнуть по файлу - в нижнем правом окне увидишь начало файла и можно прикинуть соответствует ли начало типу файла - у pdf-ки в самом начале видно %PDF а также увидеть номер LBA сектора и сравнить с известным по поиску в других программах.
(*) Можно поискать и по имени файла.

Добавлено:
Номер MFT пригодится для определения данных файла и его фрагментированости.
В меню Редактор выбери файл MFT и введи требуемый тебе номер.
В нижнем правом окне будет первый сектор этой записи. И будут видны разные аттрибуты
Наиболее интересный - 0х80 $DATA и в нём размер файла. Далее наводишь на (строку атрибутаа) и нажимаешь пробел и смотришь в конце этого открывшегося списка, после строки инициализированно.
Будет что то типа
+0: xxx cluster(s) @ yyy
Если такая строка не одна (*), значит файл фрагментирован.
Следовательно, восстановление по сигнатурам не даст возможность восстановить файл целиком. Хотя и в таком случае есть шанс что файл разделён, но в разрыве нет "помех".
(*) если в начальном списке атрибутов будет 0х20, то это означает что файл очень сильно фрагментирован. Хотя не факт что фрагменты идут последовательно - и такие тараканы у NTFS бывают.

9285
это все в DMDE надо делать?
открыл лог сканирования и нужный раздел.
Нашел файл
номер MFT29671файл начинается так
%PDF-1.5
номер LBA 2316963008

что дальше?
По имени файла искал
как я и писал раньше
Win hex нашел название файла в секторе 2336102115 со смещением 1167с2DC6CC
Что дальше?



Добавлено:

Цитата:

В нижнем правом окне будет первый сектор этой записи. И будут видны разные аттрибуты

LBA 2954387166

Цитата:

Наиболее интересный - 0х80 $DATA

там еще есть 0х80:Zone.Indetifier $DATA. Это нен нужно?
В строке 0х80 $DATA ниже такие данные
Размер:9504 Занято:12288
первый вирт кластер:0
последний виртуальный кластер: 2
Сжатие:2
Загято: 12288
размер: 9504
ингициализировано: 9504
занято кластеров: 3 начиная с 15136694

Цитата:

+0: xxx cluster(s) @ yyy

такого не вижу

Добавлено:
Сейчас заметил что в winhex название этого файла три раза пдряд встречается в секторе 2336102115
первй раз со смещением 1167с2DC6CC
потом со смещением 1167с2DC73С
потом 1167с2DC7АC

Добавлено:
Продолжил дальше искать по названию. Опять файл нашелся
Сектор 2336102116 смещение 1167C2DC86C
потом смещение 1167C2DC8EC
потом смещение 1167C2DC96C
потом смещение 1167C2DC9EC

и потом еще много раз встречается. Это нормально?

KitePark
Да, в DMDE.
Я с WinHEX малознаком, поэтому мне сложно что то сказать по нему.

Цитата:

обозвала found_2316963008_76172866.pdf

Цитата:

файл начинается так %PDF-1.5 номер LBA 2316963008

Начало соответствует PDF, но вот реперным он быть не может так как начальный сектор совпадает. Тут надо найти такой, у которого начало в одном секторе, а реально в другом.
Хотя тут есть одна очень неприятная новость - за акронисом замечено то, что он может делать много разных смещений (*) + неизвестно что он успел сделать - может он один файл перетасовал, а может половину, а может и почти все).
(*) недавно был случай, человек ресайзил раздел чем то линуксовым. Так получилось что он собрал все данные из двух частей - в одной части фалы были относительно старого начала, в другой относительно нового. То есть программа делала последовательно, до момента обрыва.


Цитата:

такого не вижу

Покажи что видишь или сделай дамп этого и следующего сектора и выложи.

Цитата:

Ещё пообщался с dmde - он предложил воспользоваться бэта-версией

В каком смысле воспользоваться? мне опять сигнатурный поиск ей провести?


Добавлено:

Цитата:

Начало соответствует PDF, но вот реперным он быть не может так как начальный сектор совпадает. Тут надо найти такой, у которого начало в одном секторе, а реально в другом

Вроде как раз так и есть. Т.е. файл по таблице должен начинаться в секторе 2316963008. Но судя по поиску имени файла через WinHex, файл начинается в секторе 2336102115
Или я нифига не понимаю...

Цитата:

Тут надо найти такой, у которого начало в одном секторе, а реально в другом.

как это сдедать?
разве нам нужно знать точное название файла не для того чтобы по нему найти его в WinHEx?

Цитата:

Покажи что видишь или сделай дамп этого и следующего сектора и выложи.

дык вроде все расписал тут
http://forum.ru-board.com/topic.cgi?forum=84&topic=4564&start=2720#2
дамп вот http://rghost.ru/8gjllQZTY

Цитата:

мне опять сигнатурный поиск ей провести?

В обычной версии нет сигнатурного поиска - поэтому поиск будет как бы новый.
А чтобы было понятней - опять же, у каждой программы свои алгоритмы, и результаты тоже.
Вот я взял и в виртуалке смоделировал удаление кучи файлов разных форматов.
Потом прогнал диск разными программами.
Photorec не нашёл одну jpg-шку., хотя она была нефрментирована и имела характерное начало и конец - то есть должна была найдена без проблем.
Get Data Back вообще не нашла rar-воский архив.
У R-studio Тоже были какие то недочёты.
А вот бэта-версия нашла всё. Правда в моём случае не было смещение, но всё ж таки.

Перезалей дамп - я просил два сектора. То есть тот что сбросил и последующий.

Добавлено:

Цитата:

как это сдедать?

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

Цитата:

В обычной версии нет сигнатурного поиска

т.е. нужно делаь опять поиск NTFS таблиц?
В прошлой версии было найдено куча разделов но восстановление данных с них принесло только битые файлы. Сейчас т.е. может лучше получится?
В чем смысл? Я же уже провел сигнатурный посик с помощью Active File Recovery и как мне кажется все фало было найдено. Единственный минус - потеряна структура каталогов.
Сейчас с бета версией есть шанс что получится восстановить с сохранением имен и структуры?
Что насчет изысканий по поиску смещения фалов? мы их продолжаем?

Добавлено:

Цитата:

Перезалей дамп - я просил два сектора.

вот
http://rghost.ru/7wcfXnpZ9

Цитата:

Это нужно найти файл, который найден сигнатурно и он цел (хотя бы начало) а в DMDE восстанавливается неправильно

именно такая ситуация и есть с этим pdf. Восстанавливаю его через DMDE - он не открывается. Восстановленый по сигнатурному поиску спомощью Active Recovery - открывается нормально.

KitePark

Цитата:

Сейчас с бета версией есть шанс что получится восстановить с сохранением имен и структуры?

Не буду гарантировать, поэтому процитирую написанное мне
Можно новую версию DMDE попробовать, она определяет смещение не только по индексам, но и по файлам известных типов.


Цитата:

но восстановление данных с них принесло только битые файлы.

Ну, как минимум, указанная выше pdf-ка должна была восстановиться нормально.
Хотя ... тот же кэш, мог сбросить даже в нормально расположенный файл мусор.

вот эти два файла
http://rghost.ru/7My9hLhfP
http://rghost.ru/6PfXfJ5My

Добавлено:

Цитата:

указанная выше pdf-ка должна была восстановиться нормально.

да. беру свои слова обратно. Она нормально восстановилась. Просто вьевер проглючил у меня.
т.е. нужно продолжать делать это?

Цитата:

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

KitePark

Цитата:

Восстанавливаю его через DMDE - он не открывается. Восстановленый по сигнатурному поиску спомощью Active Recovery - открывается нормально.

Странно. По данным из MFT всё соотвествует.
Может ты из другого тома пытался его восстановить.
Вот на всякий случай http://plasmon.rghost.ru/8KzLX7Md5/image.png список нескольких файлов, данные о которых я извлёк из имеющихся дампов.
Указан номер начального сектора и число секторов.
Можешь попробовать сделать дамп сам - соответствующие значения став в нужные поля. После сохранения дампа переименуй - хотя бы расширение и попробуй открыть.

Кхе,кхе. Что то я уж стал подзабывать обращать внимание на то, какая версия DMDE используется.
А ведь у тебя она ломанная - как раз в такой может восстанавливаться "битый" файл, при том что нормальная версия восстановит полностью исправный файл.
И если это подтвердится, то сам виноват в своих мучениях.

Вторая ссылка - моя.

Цитата:

Странно. По данным из MFT всё соотвествует.

да. этот файл нормально восстановился. просто у меня вьевер глючит. Я выше уже писал об этом.

Цитата:

она ломанная

да. каюсь.

нашел другой файл. он точно не восстанавливается нормально через DMDE и нормально открывается после сигнатурного восстановления.
файл называется 5trendov.pdf
нашел его на томе через DMDE, но судя по содержимому это не PDF, либо он сильно покоцан. номер сектора в DMDE 2954724882. MFT 198529. По факту файл находится в секторе 3078048240, судя по поиску.
Перешел по номеру MFT. Вижу следующую картину
+0: 69 clusters@26028674

вот дамп и файлы
http://rghost.ru/8WyRf9gtd
http://rghost.ru/86hbRy6Sr
Я уверен что в секторе 3078048240 этот pdf фалй начинаеися, но почему то если смотреть на содержание этого сектора, то название фала не читается совсем в DMDE

KitePark

Цитата:

Я выше уже писал об этом.

Я заметил, но ответ писал когда ещё не было "Добавлено".

Цитата:

да. каюсь.

Я не поп и не отмаливаю грехи - главное чтобы дальнейшая работа велась с нрмальной версией. чтобы исключить проблемы, описанные выше.


Цитата:

либо он сильно покоцан. номер сектора в DMDE 2954724882. MFT 198529. По факту файл находится в секторе 3078048240, судя по поиску.

и далее
Тем не менее, в архиве лежит dev0_lba1781320720_2.bin - что соотвествует началу файла по данным из ранлиста. Сам рассчитал или как?
Я чуть выше написал про мусор, но не обязательно дело в нём - на самом деле запись 198529 может быть об удалённом файле. Соответственно, его место может занято другими.
Вдобавок, надо обращать внимание на обозначения в панели файлов - http://dmde.ru/manual/filepanel.html
Всё что не обычный файл (или папка) не обязательно является правильным.
По логике, если ты откроешь том по варианту 1 и зайдёшь в папку Root, то увидишь более актуальное дерево папок и "живые" файлы.

Если что, можешь прикреплять скриншоты, той же панели файлов, чтобы было более понятно о чём речь.

Доброго времени суток.

Хочу восстановить данные с HDD WD my pass.ultra 1Тб. Момент и причины сбоя неизвестны. Диск использовался как подключенный к роутеру на постоянной основе (редко снимался). Контроллер вшит, подключение только по usb. В винде заставляет все висеть(. В линукс говорит следующее:

Код:
I/O error, dev sdc, sector 966896256
Buffer I/O error on device sdc1, logical block 120861776

eugenelee
Если с винтом физические проблемы, то попытки вычитывания (особенно учитывая известную болячку WD) могут привести и к более печальным последствиям.
Ну это как предупреждение.
В принципе, если есть сбойные сектора и их не много, то можно попробовать вычитать нужное - возможно что сбойки не на их поляне.
Чтобы ОС типа винды не мучила диск обращением к структурам ФС можешь под линуксом в DMDE сделать MBRoff (применит изменение разметки).
Далее можешь в DMDE открыть том и попробовать восстановить нужное.
Для просмотра показателей SMART используй то, что может работать с внешниками.

9285
Спасибо.
Пока получаестся средствами r-studio под линуксом вытаскивать файлы, не все конечно но процесс идет.

9285
я попутал немного.
2954724882 это сектор где MFT лежит для этого файла
http://rghost.ru/6VRQxNCBJ
панель файлов.
http://rghost.ru/689vqmVvB
Это я открыл том после посика ntfs.
те папки что зеленые - были на разделе E. А желтые папки это как раз те что были на мертвом разделе F.
Просканировал весь диск бета версией программы.
Файлы так же восстанавливаются битыми.



Добавлено:
а вот панель файлов непосредственно там где файлик этот лежит
http://rghost.ru/7QksKRYRs