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

9285

Цитата:

Результаты проверки сохраняются в журналах винды. Не помню в каком, но если исходить из того что 2003 это как бы ХР, то искать по Источник-у Winlogon - или по времени когда была проверка.

Боюсь, что ничего там не сохранилось - я не выдержал этого горя (4 ТБ !) и ресетнул комп. Потому, как шло оно более получаса, и заканчиваться не собиралось - сил не было больше терпеть. Тем более, чем дальше, тем... гаже
В смысле, больше "исправлений" этот чекдиск сделает, больше данных загадит. Я посчитал ресет наименьшим из зол, всё равно выйти корректно из этой проверки не удавалось.
Во всяком случае, слава R-Studio, бэкап удалось спасти (и развернуть), а большего мне и не надо. Потом, уже из Windows PE запускал разные дисковые менеджеры (Акронис, Парагон, etc) - все они ругались на неправильную геометрию/неподдерживаемый диск (4ТБ), и что либо делать с ним отказывались. Какой-то, впрочем, удалил раздел, но как оказалось не "до конца". В общем, этот гавнёвый чекдиск к GPT-разделу "приклеил" MBR-раздел - эдакий "гибринт" получился. Неудаляемый причём ничем . В общем, загрузился я в старый, добрый DOS, завёл Victoria и зачистил начало диска. А уже после этого 2008-й сам мне предложил диск инициализировать, где я и выбрал GPT.
На этом доклад окончен, будем считать что проблема решена.
Одного не пойму: какого лешего? Какого лешего этот чекдиск завёлся вообще? Какого лешего он полез править GPT-раздел, ведь 2003-й сервер нормально их понимает.
В общем, полез гуглить, как извести этот чекдиск (отключить автозапуск).

9285, большое спасибо, только когда тыкнули носом, и только сейчас заметил, что натворил (( Лучше ничего в панике не делать.. Значит, делаю, как говорил постом ранее Alex_Green -- запускаю поиск NTFS по всему диску, сохраняю скрин и логи.. Вопрос -- раздел я уже никак не восстановлю? В лучшем случае -- часть файлов, без каких-либо папок и нормальных имен?

Hotery
Если ты беспокоишься из-за глупого предсказания "знатока" с зоны, то выкинь это из головы.
Если винда не работает с разделом, то она ничего туда не запишет - главное чтобы не запустилась автоматическая проверка и не исправила "ошибки". Но раз это не произошло до сих пор, то скорей всего ошибки такие, с которыми чекдиск не справился. Впрочем, лучше всё таки не расслабляться и если вдруг будет попытка запуска - отменить.
Ну а раз чекдиск и винда ничего не поменяли в восстановленном разделе, то практически 100% что структура прежнего Data цела полностью. Можешь воспользоваться поиском NTFS, хотя по мне быстрее найти бутсектор раздела и открыть том сразу - потом прописать в таблице.

ситуация:
физически один винт, разбит на C и D. стало место мало на первом, пользователь решил увеличить. под вин7 поставил акронис - англ версии, по не знанию сделал сначала merge, папку не указал на C для файлов диска D - после перезагрузки были ошибки, процесс не завершился, потом догнал что надо делать ресайз и 10 гигов перекинул на диск С ресайзом. все робит типа норм, потом замечает что все файлы на D не читаемы, т.е. их видно, размер и расширения верные, а родными программами не открываются, например ВОРД пишет что поврежденное содержимое.
как их можно восстановить? т.е. тут не удаленные файлы восстановить надо а типа MFT слетела или что, что конкретно поломалось?
подскажите как можно вернуть файлы?
весь софт рекомендуемый по восстановлению файлов пробовали - они естественно ничего не находят, так как файлы типа живые - не удаленные, но нутро не верное.

alexul
Скорей всего "отделение жира от мяса" получилось после первого этапа. И если бы притормозили тогда, то какие то надежды на восстановление по ФС были. Но второй этап скорей всего можно сравнить с мясорубкой, превращающий всё это в "фарш".
Здесь можно посоветовать восстановление по сигнатурам. Есть и другой вариант, но он достаточно сложен - определять смещение данных. Если смещение у всех (или хотя бы бОльшей части) одинаковое, то можно попробовать скорректировать структуру раздела.

просвяти на счет восстановления по сигнатурам пжста? и по второй вариант - про смещения - как экспериментировать со смещением?
может софт какой посоветуешь?

Добавлено:
т.е. поиск по сигнатурам - это поиск по винту на предмет опознавания типовой структуры файла определенного типа? т.е. если структура данных на секторах винта похожа по строению на файл doc - то софт распознает этот кусок секторов как файл ворда?

Цитата:

т.е. если структура данных на секторах винта похожа по строению на файл doc - то софт распознает этот кусок секторов как файл ворда?

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

а если MFT нарушена, то получается инфы по фрагментам и не найдешь? т.е. если файл физически был размещен например на 4-х участках (группах секторов винта) - то никак теперь их принадлежность к к одному файлу уже не узнаешь без MFT?
и могла ли где-нить сохраниться исходная разметка MFT - которая была до манипуляций?

alexul
MFT не нарушена, так как доступ к файлам имеется. Другое дело что там не то.
То есть (примитивно) - указано что файл начинается в кластере 100500, а реально он может быть в другом месте; причём в случае применения данного УПД смещение может быть не кратно кластеру. Более того, механизм действия УПД неизвестен и есть лишь косвенные данные о том, что действия делаются не последовательно а хаотически. И это сильно усложняет возможность восстановления.

спасибо бро что просвятил, по сигнатурам часть инфы вроде находит.

Цитата:

бро

А по русски нельзя?

спасибо Россиянен

Добавлено:
вот хорошо написано про поиск со смещением ручками:

Цитата:

Практический пример определения смещения файлов в NTFS (определение виртуального начального сектора раздела).

Итак, что нам нужно.
1. Дисковый редактор WinHex (в примере использована версия 15.0 SR-2).
2. Документация Linux NTFS (легко найти в сети), далее [1].
3. Авторекаверилка R-Studio (в примере версия 4.0 Demo).
4. Моск Smile.

Алгоритм поиска смещения.
1. Выбираем реперный файл. Как уже заметили выше, в качестве такого файла удобно использовать документацию от программы. Вы должны точно знать, что этот файл есть на восстанавливаемом разделе, и у Вас должна быть его точная «здоровая» копия. Файл должен быть размером не менее ~1 КБ (чтобы не оказался резидентным). Я выбрал файл ReadMeRu.txt из каталога редактора DMDE.
2. Ищем файловую запись реперного файла. Для этого запускаем WinHex, открываем пострадавший физический диск. Нажимаем Ctrl+F, вводим имя файла ReadMeRu.txt (с расширением), Unicode, Search: Down, чекбоксы оставить неотмеченными, ОК (искать будет долго). Найденные секторы надо проверить на соответствие Файловой записи MFT ([1], п. 4.11), причем запись должна быть используемой (два байта по смещению 0x16 байт от начала записи должны быть 01 00). В моем случае первой нашлась запись другого файла: имя совпадает, но файл из другого каталога – у меня несколько версий DMDE (продолжение поиска дало желанный результат). Я легко определил, что файл не тот, потому что опыт проводился на живой файловой системе… Если ФС повреждена, правильно найти файл подобным образом будет проблематично, т. к. могут быть имена с одинаковым именем в разных каталогах, не говоря уже о других проблемах. Поэтому рационально использовать NTFS-сканер типа того, что есть в R-Studio, но я там не нашел возможности посмотреть начальный сектор файловой записи для выбранного файла. Есть еще мой Media Workshop, но он еще не доделан, хотя сканер уже давно функциклирует (выкладывать в сеть недоделку нет желания). В общем, тут остается неприятный момент с одинаковыми именами в разных каталогах.
3. Ищем содержимое реперного файла. Для этого открываем «живой» экземпляр реперного файла в WinHex, выделяем мышой первую строку, затем меню Edit – Copy block – Hex values (в случае других типов файлов первая строка может не прокатить – там зачастую заголовок, который одинаков для всех файлов такого типа). Теперь открываем проблемный физический диск в WinHex, Alt+Ctrl+X – окно поиска Hex значений. Вставляем искомые значения Ctrl+V, Search: Down, Cond: offset mod 512 = 0, остальные чекбоксы не отмечены, ОК (искать будет долго). Итак, я нашел начало файла, я вижу текст Readme от DMDE. Но я не знаю, от какой версии. Начал искать в браузере WinHex и обнаружил, что это Readme из каталога DMDE, расположенного в «Program Files\DMDE», а не в «Storage\Programs\DMDE\DMDE Win GUI», где я вначале нашел реперный файл. Т. е. опять проблема версий.

Лирическое отступление
Очевидно, что в моем случае реперный файл выбран неудачно. ИМХО нужен текстовый файл, который имеется на диске в одном экземпляре. Я попробовал на другом ReadMe – от AsmEdit, содержимое нашел правильно с первого раза (примерно в 10% от начала раздела объемом 61 ГБ), но с файловой записью возникли конкретные трудности, потому как имя файла Readme.txt есть и у других программ. В общем, если имя у файла распространенное, нужно искать файловую запись по реконструированной структуре в NTFS-сканере, который может показать для выбранного файла номер начального сектора. Следующим кандидатом стал файл Filemon.hlp (не текстовый) от программы FileMon, поиск содержимого осуществлялся по нескольким первым строкам hex-значений, поиск файловой записи – как обычно, только по имени. Поиск файловой записи дал индексную запись (INDX, [1], п. 4.16), это было очевидно и проблемы не создало. Продолжение поиска дало правильный сектор! Поиск содержимого дал правильный сектор с первого раза. Так что правильный выбор реперного файла имеет очень существенное значение.

4. Определение смещения начала реперного файла по ФС. Смещение начала файла от начала раздела в NTFS определяется как FromCls*ClsSct, где FromCls – начальный кластер файла, ClsSct – количество секторов на кластер. Размер кластера NTFS обычно 8 секторов. Теперь наша задача – найти номер начального кластера. Это несложно сделать в WinHex. Переходим к найденной файловой записи реперного файла ([1], п. 4.11). По смещению 0x14 байт от начала записи смотрим смещение начала списка атрибутов, обычно это 0x38 байт. Переходим по этому смещению и видим начало первого атрибута. В начале заголовка каждого атрибута два четырехбайтовых поля, расположенных последовательно: идентификатор типа атрибута и размер атрибута в файловой записи. Первый атрибут обычно имеет тип 0x10 (STANDARD_INFORMATION), на диске это выглядит как 10 00 00 00 48 00 00 00 (не забываем, что в каждом поле нужно инвертировать последовательность байт, т. е. размер атрибута 0x48 байт, а не 0x48000000). Размеры атрибутов одного типа могут быть различны, 0x48 дано для примера. Атрибуты в файловой записи расположены последовательно, нам нужно найти атрибут с идентификатором 0x80 (DATA). Т.к. размеры атрибутов указаны, мы просто переходим на размер атрибута и оказываемся в начале следующего атрибута. В WinHex Вы можете использовать окно Alt+G (Bytes, Hexadecimal, Current Position) для перемещения по цепочке атрибутов (обычно она включает атрибуты с типами 0x10, 0x30, 0x80; тех что с типом 0x30 может быть две штуки). Итак, вы в начале атрибута 0x80 DATA. Этот атрибут у Вашего реперного файла должен быть нерезидентным (мы специально искали файл не менее килобайта). В таком случае смещаемся от его начала на 0x20 байт и видим смещение списка экстентов, в большинстве случаев оно равно 0x40 байт. Смещаемся от начала атрибута DATA на 0x40 байт – мы в начале списка экстентов (ранлиста). Ранлист – это последовательность структур, указывающая размещение файла. Нас будет интересовать только первый экстент. Сейчас курсор в первом байте ранлиста. Посмотрите на этот байт. Его первая цифра означает количество байт поля смещения экстента, вторая цифра – количество байт поля размера экстента. Далее расположено поле размера экстента, за ним – поле смещения экстента. Например, в моем файле ранлист такой 31 - 04 - 81 2F 32 - 00. Видно, что под размер экстента отведен один байт, под смещение – три байта, размер равен 4 кластерам, а смещение 0x322F81 кластерам (не забываем перевертывать байты). После первого экстента расположен байт 00, он замыкает ранлист (если экстентов несколько, в этом байте начнется следующий экстент, и его смещение задается относительно начала предыдущего экстента). Итак, мы нашли смещение начала файла – это 0x322F81 (3293057) кластер, или 26311688 сектор от начала раздела при размере кластера 8 секторов (будьте внимательны, у Вас может быть другой размер кластера, например встречаются односекторые кластеры после преобразования FAT => NTFS).
5. Определение виртуального начального сектора раздела. Переходим в начало содержимого файла, которое мы нашли ранее. Смотрим номер сектора. Вычитаем из номера сектора смещение реперного файла, рассчитанное по ранлисту (в примере это 26311688), результат – виртуальный начальный сектор раздела, т. е. тот сектор, в котором должен был начинаться раздел для данной файловой системы (не стоит искать там бутсектор). Результат достигнут. После перемещения на 26311688 секторов от начала содержимого файла я наблюдаю на экране бутсектор раздела (эксперимент проведен на живой ФС).

Такую процедуру надо повторить для нескольких файлов, чтобы более/менее точно определить смещение. Если смещений несколько, как было отмечено выше, поиск этих смещений гораздо сложнее, у меня нет идей, как это можно сделать простым путем.

первоисточник:
http://www.ihdd.ru/forum/kak-i-chem-uznat-smeschenie-vosstanavlivaemyh-failov-t7507.html

alexul

Цитата:

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

Переходите ко второму этстенту/data-run и видите, что там что угодно, но только не ASCI код чего-то вразумительного. И как тут быть...???...

alexul
Молодец что сам нашёл, действительно хорошее описание.
Но только надо учесть один момент, о котором я писал ранее - то, что смещений может быть несколько.
То есть, хххх файлов смещёно на zzz кластеров, а yyyyyyy на другое количество. И это для варианта когда поиск делался бы после первого этапа.
Впрочем, всегда есть шанс что именно ты везунчик и будет всего одно смещение, ну или два.

Tau_0
В случае УПД Акронис возможно всё, но вообще то логично делать передвижки целиком.

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

Tau_0
Проблемы с восстановлением после работы с партмагоидом, могут быть связаны с (в том числе) разными смещениями самих файлов, или записей MFT но не фрагментов самих файлов.

9285
Тебе бы следовало сначала понятие файла определить, а уже потом об конкретных атрибутах говорить...
ЗЫ Собирался я в своё время этот вопрос задать Antech (он мне тогда давно в ворде своё эссе сбросил...), но я не успел --- слишком тогда я был зелен...

Tau_0

Цитата:

ЗЫ Собирался я в своё время этот вопрос задать Antech (он мне тогда давно в ворде своё эссе сбросил...), но я не успел

А почему он пропал, кстати? Простите за оффтоп.(

zybex15
Очень интересный вопрос. В своё время он ушёл на хобот, но потом внезапно перестал писать в темах. Лично мне неизвестно по какой причине, как и некоторым знакомым участникам. Надежда лишь на то, что у него всё нормально и ничего плохого не случилось.
Tau_0
Если ты хочешь попускать пузыри, то лучше сходи в твоё любимое болото и там, под крылышком вертухаев, сделай это. А здесь постарайся писать по делу, и крайне желательно читать написанное осмыслено.

9285
Да, тоже на это надеюсь...

9285

Цитата:

А здесь постарайся писать по делу, и крайне желательно читать написанное осмыслено.

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

А файл (грубо говоря --- речь только о нерезидентных data...) есть отобрахение VCN в LCN.
Тогда часть файла будет посчитана относительно нового начала раздела/тома, а часть относительно старого начала. Это при условии, что данные не перекрыты…
Так я понимаю одну из неприятностей партмагоидного смещения…

ЗЫ Ты на зоне немало пызырей пустил, но потоп в том болоте так, что даже пузырей не осталось…

Tau_0
Читай написанное мною выше.

Цитата:

В случае УПД Акронис возможно всё, но вообще то логично делать передвижки целиком.

И учитывая твою любовь гордиться своей программерской "кровью", я бы ни разуу не удивился если бы узнал что ты один из разработчиков этого УПД. Потому как столько дури там и она, как я понимаю, принципиально не убирается. Всё в твоём стиле, который в народе называется "отморожу уши назло маме".
У меня "кровь" обычного юзера, но знающего об устройстве NTFS чуть больше среднего. Тем не менее я примерно представляю как она устроена, её возможности и могу представлять как делать подобные (и не только) передвижки с минимальным риском проблем с данными.
Давай рассмотрим твой пример передвижки начала раздела вправо. Естественно, часть данных, находится в начале раздела. В таком случае вполне логично переместить их в ту часть раздела, которая будет впоследствии задействована текущим. При этом файл, который ранее был фрагментирован может одновременно "склеиваться"; но главное его координаты заносятся относительно старого начала раздела. И при всём этом вполне реально задействовать и возможность журналирования действий самой файловой системой, и конечно использовать алгоритмы перемещения в ней же - файл записывается в новую область, проверяется считываемость его в новом месте, делается запиь транзакции, меняются данные в записи MFT и других служебных файлах о новом местонахождении, освободившееся место помечается таковым. Какой либо сбой, завис и т.п. не приведёт к потере данных. Вроде бы как много и муторно, но ведь надёжно. Когда все необходимые перемещения сделаны, делается пересчёт MFT и перезапись бутсектора. Тут уж не знаю как это сделать побыстрее, а главное надёжне, но наверное пересчитать в уме, а потом сразу переписать $MFT и BR. Хотя можно в реалтайме переписывать каждую запись и пр.
Мне думается что в акронисе всё это делается одновременно, причём в несколько потоков и в несколько смещений - последнее означает что раздел сначала сдвигается на один сдвиг, а потом переносится на другой (тому есть косвенные подтверждения). В таком случае действительно возможно всё.

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

Ну и самое главное. Ты конечно же начнёшь традиционно усераться и винить мою предвзятось, но теперь почитай написанное Antech-ем и то, что ты написал по поводу его фразы.

Цитата:

Ранлист – это последовательность структур, указывающая размещение файла. Нас будет интересовать только первый экстент.

То есть речь идёт лишь о начале файла и как быто, что в пределах одной записи нет разных смещений. Впрочем и про разные смещения гуру написал, хотя я думаю что под таковыми он скорей подразумевал вариант не записей одного файла а разных - как раз таки такое очень часто и густо имеется при подобных превращениях. И именно поэтому в DMDE файлы одного бывшего тома нередко восстанавливаются с разных найденных томов (с разными началами разделов).

PS. На болоте газа выше крыши. Недавняя тема в которой договорились до того что гемоблок винта герметичен потому что он гермо, и там вообще мембрана выравнивающая давление это как полёт во времена 20мб винтов. Причём упор на гермо делался тем, кто как бы по специфики своей работы физически разбирает винты. Так что маразма там (кроме озвученного) - мама не горюй.

9285

Цитата:

Вроде бы как много и муторно, но ведь надёжно.

Красиво ты Нью-Васюки разрисовал…

Но только так при всём желании не реализовать…
Как работает драйвер NTFS рассказано в самых общих чертах, а Microsoft глубоко прикрыла эту информацию. А для этого горы информации нужны. Поэтому организовать тесное взаимодействие с Windows невозможно..

Конечно я непричастен к акронису, но знаю, что он построен на базе NTFS драйвера Linux. Разработчики коего убили много сил и времени, но всё же его сумели создать. А насколько он соответствует спецификациям Microsoft не знает никто.

Напомню, что отрезки следуют враскорячку.
См. КартинкуСсылка c иллюстрацией отображения VCN ===>LCN

Тут не до того, чтобы при переносе отрезки дефрагментировать, --- дай Бох еще дальше не подробить, когда свободного места не так и много…

Я думаю, что файл находится и относительно старого и относительно нового раздела потому, что он перенесен в новое место, но и на старом местоположении не перекрыт/затёрт… Фактически он пока цел в двух местоположениях…

Tau_0

Цитата:

Но только так при всём желании не реализовать…

Есть обоснования этого, или лишь бы попытаться оправдаться? Я не вижу препятствий для этого, в том числе и через сторонний драйвер. И если бы такое не было возможно, то по определению, сторонние драйверы позволяли бы работать с NTFS лишь на чтение - что собственно и было на начальной стадии.

Цитата:

c иллюстрацией отображения VCN ===>LCN  

Я знаю твою любовь к заумным картинкам, копипастам и множественным расчётам. Но они традиционно ни о чём? Или к чему ты её показал?


Цитата:

Я думаю, что файл находится и относительно старого и относительно нового раздела потому, что он перенесен в новое место, но и на старом местоположении не перекрыт/затёрт… Фактически он пока цел  в двух местоположениях…

Во первых, речь шла не об одном файле а о разных файлах одного тома. Хотя можно сказать и об одном, но в таком случае в одном томе он будет полноценный, в другом или пустышка или мусор.
Опять же, не верующий мне может спросить автора программы. Но если неверующий подумает, то вспомнит что DMDE не работает с сигнатурами и самими файлами и информацию об их положении может брать из записей MFT и индексов (насколько я понимаю).
А то, о чём пишешь ты может быть (хотя не уверен в этом) при восстановлении по сигнатурам.

9285

Цитата:

DMDE не работает с сигнатурами и самими файлами и информацию об их положении может брать из записей MFT

Может и такое быть, что обломки старой MFT сохранились, об этом и без твоего ответа задним умом после своего поста подумал...

ЗЫ А написал я свои посты только потому, что alexul дал ссылку на статью Antech, к которому у меня накопились вопросы... Вот я и пытаюсь, как умею, эту статью и рядом лежащие вопросы обсудить. Ты уж не обессудь...

Tau_0

Цитата:

Может и такое быть, что обломки старой MFT сохранились, об этом и без твоего ответа задним  умом после своего поста подумал...

Цитата:

Вот я  и пытаюсь, как умею, эту статью и рядом лежащие вопросы обсудить.

Обсуждать можно, но к чему выдумывать несуществующую проблему? Я тебе потому и предложил разобраться с подобным случаем чтобы ты мог понять какие там происходят изменения и что более характерно для них. Уверен что если сделаешь такое, особенно несколько и разных, то многие твои вопросы самоулетучаться.

9285

Цитата:

Обсуждать можно, но к чему выдумывать несуществующую проблему?

Да вроде как проблема существующая... --- Нефрагментированные файлы DMDE выбирает и копирует нормльно, а фрагментированные не всегда...

Tau_0

Цитата:

Нефрагментированные файлы DMDE выбирает и копирует нормльно, а фрагментированные не всегда...

Сам придумал или есть тому подтверждения? И то, что это происходит в неломанных версиях?

Приветствую гуру форума. Нужна помощь в восстановление баз outlook 2007 *.pst после форматирования раздела, пересоздания мбр и записи 300 мб инфы. Файл размером 1 гб. Папку с базами видит, archive.pst размером 2гб видит, а outlook.pst размером 1 гб нет. Перепробовал:
\R-Studio.v7.5., Restorer Ultimate, unformat, Ontrack.EasyRecovery.Professional.v6.22,
самый эффект Hetman Partition Recovery. И RAw и восст mft, ниче не помогло(
Большая просьба помочь, письма очень важные от опполчения ДНР, копии нету

viking4
В зависимости от того чем ранее и сейчас форматировали записи MFTмогут быть повреждены частично или не очень. Если сохранилась запись об outlook.pst то есть шанс вытащить этот файл.
Но запись 300 мб поверх может тоже привнести свою толику дерьмеца, как затерев записи MFT, так и частично требуемый файл.
Ну и ещё ложка дёгтя - файл скорей всего был фрагментирован.
Что можно предпринять:
- в DMDE устроить поиск NTFS а потом по результатам поиск по имени файла
- попробовать сигнатурный поиск. Насколько помню, photorec pst-шные файлы ищет. Только если будешь использовать его, то в маске файлов выбери этот тип чтобы меньше восстанавливало файлов.
Думаю что в случае восстановления файла всё равно прийдётся восстанавливать ещё и с помощью спецпрог по работе с почтовыми базами.