Надежность NTFS — это одно, а ошибочно удаленные файлы — совсем другое. Файловая система, даже такая мощная, как NTFS, бессильна защитить пользователя от себя самого. Прекрасно, если удаленный файл сохранился в "Корзине", но что делать, если там его не окажется? Как поступить, если ты случайно удалил нужное файло, а теперь в отчаянье кусаешь локти и прочие части тела? Главное — не паниковать, а о том, как справиться с этой бедой, я сейчас расскажу.
Ни в том, ни в другом случае физического удаления файла не происходит, и он может быть легко восстановлен. Легкое и быстрое восстановление возможно до тех пор, пока не будет затерта файловая запись (FILE Record), принадлежащая этому файлу и хранящая его резидентное тело или список отрезков (run-list) нерезидентного содержимого. Утрата файловой записи крайне неприятна, поскольку в этом случае файл придется собирать по кластерам. При этом стоит заметить, что чем сильнее был фрагментирован удаленный файл, тем сложнее будет эта задача. К счастью, в отличие от FAT, NTFS не затирает первого символа имени файла, что значительно упрощает восстановление.
Предположим, нам необходимо восстановить базу данных объемом в несколько гигабайт. Можно, конечно, подключить второй винчестер, скопировать ее туда, а затем обратно. Однако подумай, сколько же это займет времени, не говоря уже о том, что сервер лучше не выключать, а "горячую" замену поддерживают далеко не все жесткие диски!
Другой недостаток подобных утилит — слишком медленная работа. Вместо того чтобы найти один‑единственный файл, имя которого нам известно, они проводят полномасштабные "маневры", сканируя весь раздел целиком. При работе с большими дисками на это уходит от одного до нескольких часов, причем это время фактически тратится впустую.
С другой стороны, утилиты, вносящие изменения непосредственно в структуру NTFS, рискуют серьезно повредить дисковый том, после чего ему не помогут даже профессионалы. Настоящие хакеры не доверяют никакому коду, кроме созданного лично ими, особенно, если исходные тексты недоступны, а документация туманна и двусмысленна. Различные версии NTFS отличаются друг от друга. Последние радикальные изменения произошли в Windows XP (NTFS версии 3.1) — массив последовательностей обновления (Update Sequence Number-n-Array) переместился на шесть байтов вперед, а его место было отдано под выравнивание и поле номера текущей файловой записи (Number of this MFT Record). С тех пор формат файловой системы не претерпел каких‑либо существенных архитектурных изменений.
Наконец, возможна и такая ситуация, когда утилит восстановления просто не окажется под рукой в тот момент, когда вам срочно потребуется восстановить какой‑нибудь ценный файл. Законов Мэрфи еще никто не отменял! В этом случае вам придется рассчитывать только на свои силы.
Теоретически грамотный и правильный подход состоит в следующем. Извлекаем из загрузочного сектора указатель на MFT, извлекаем из нее первую запись (она описывает $MFT), находим атрибут $DATA (80h), декодируем список отрезков (data runs) и последовательно читаем все записи в MFT, анализируя содержимое атрибута $FILE_NAME (30h) — имя файла. Обрати внимание, что таких атрибутов у файла может быть несколько. Этот же атрибут хранит ссылку на родительский каталог. Поэтому, если несколько одноименных файлов были удалены из различных каталогов, то необходимо выяснить, какой именно из них должен быть восстановлен.
Практический подход выглядит следующим образом. В девяти случаях из десяти файл $MFT не фрагментирован и располагается в самом начале диска. Имена файлов хранятся по смещению EAh от начала сектора, в начале которого расположена сигнатура FILE0. Поэтому можно просто запустить любой дисковый редактор, ввести имя восстанавливаемого файла в кодировке UNICODE и дать редактору указание искать его по смещению F0h от начала сектора.
Когда же искомая строка будет найдена, необходимо проверить, находится ли в начале сектора сигнатура FILE0. Если такой сигнатуры в начале сектора нет, следует продолжить поиск. Двухбайтовое поле по смещению 16h от начала сектора содержит флаги записи: 00h — запись не используется или была удалена, 01h — запись используется, 02h — запись используется и описывает каталог. Встречаются и другие значения, например, 04h, 08h. Эти значения не документированы. Возможно, что именно ты сможешь пролить свет на этот вопрос?
Исправляем 00h на 01h, записываем изменения и… Ничего не выходит?! А что же ты хотел! Ведь помимо этого необходимо выполнить еще несколько действий. Во‑первых, следует сообщить файлу /$MFT:$BITMAP, что данная запись MFT вновь используется. Во‑вторых, необходимо исключить из файла /$BITMAP номера кластеров, принадлежащие восстанавливаемому файлу. Наконец, необходимо перестроить двоичное дерево индексов, хранящее содержимое каталога.
Первые два пункта не представляют серьезной проблемы, но вот над последней задачей придется повозиться. Хотя ее можно существенно упростить, просто запустив chkdsk с ключом /F. Утилита chkdsk самостоятельно найдет "потерянный" файл и внесет все необходимые изменения в файловую систему. От вас потребуется только установить флаг по смещению 16h в единицу, а все остальное сделает chkdsk. После этих нехитрых манипуляций восстановленный файл окажется в своем родном каталоге.
С нерезидентными файлами, хранящими свое тело вне MFT, ситуация обстоит не так плачевно, хотя и здесь проблем тоже хватает. Порядок размещения файла на диске хранится в списке отрезков (run-list) внутри файловой записи в MFT. При этом, поскольку файловая запись уже затерта, возможен лишь контекстный поиск по содержимому. Запускаем дисковый редактор, вводим последовательность, заведомо содержащуюся в удаленном файле, но не встречающуюся во всех остальных, и даем редактору команду начать поиск. Для ускорения поиска можно искать только в свободном дисковом пространстве (за это отвечает файл /$BITMAP).
Восстановление нефрагментированных файлов осуществляется элементарно. Достаточно просто выделить группу секторов и записать ее содержимое на диск.
Единственная проблема заключается в определении оригинальной длины. Некоторые типы файлов допускают присутствие "мусора" в своем хвосте. В этом случае можно следовать правилу, гласящему, что перебор лучше недобора. Однако это справедливо не для всех файлов! Если конец файла не удается определить визуально (например, pdf-файлы завершаются сигнатурой %%EOF), проанализируй заголовок файла. Как правило, наряду с прочей полезной информацией там присутствует и размер файла. В данном случае все зависит от структуры конкретного файла, и универсальных рекомендаций дать невозможно.
Если восстанавливаемый файл фрагментирован, то ситуация осложняется. По правде говоря, она практически безнадежна, поскольку, чтобы собрать разрозненные цепочки кластеров воедино, необходимо хорошо знать содержимое удаленного файла. В этом смысле NTFS восстанавливается намного хуже, чем FAT. Последовательность фрагментов файла, хранящаяся в FAT в виде однонаправленного списка, очень живуча. Если список не поврежден, достаточно лишь найти его первый элемент (а сделать это проще простого, поскольку он будет указывать на заголовок файла с вполне предсказуемым содержимым). Даже если список "разрубить" на несколько частей, они продолжат жить собственной жизнью, и останется лишь подобрать комбинацию, в которой их необходимо склеить воедино. Список гибнет лишь при полном затирании FAT, что случается, прямо скажем, не часто.
В NTFS же порядок фрагментов файла хранится в крохотных списках отрезков, и их гибель — обычное дело, после чего мы остаемся один на один с миллионом беспорядочно разбросанных кластеров. С текстовыми файлами еще можно работать, но что делать, если файл представлял собой электронную таблицу, графическое изображение или архив? Без знания стратегии выделения дискового пространства восстановить такой файл невозможно. Порядок, в котором драйвер файловой системы находит подходящие свободные фрагменты, не предопределен. Он варьируется в зависимости от множества обстоятельств, однако некоторые закономерности в нем все же присутствуют.
В ходе анализа списков отрезков сильно фрагментированных дисков мне удалось установить следующие закономерности. Сначала заполняются самые большие "дыры", причем заполнение происходит в направлении от конца зоны MFT к концу диска. Затем драйвер файловой системы возвращается назад и начинает заполнять "дыры" поменьше. Так продолжается до тех пор, пока файл не оказывается на диске целиком. В последнюю очередь заполняются "дыры" размером в один кластер.
Просматривая карту диска, представленную файлом /$BITMAP, мы можем в точности восстановить порядок размещения фрагментов удаленного файла, наскоро собрав их воедино. Во всяком случае, теоретически такая возможность существует. На практике же на этом пути нас ждут коварные препятствия. Дело в том, что с момента создания восстанавливаемого файла карта свободного дискового пространства могла радикально измениться. Всякая операция удаления файлов высвобождает одну или несколько "дыр", хаотично перемешивающихся с "дырами" восстанавливаемого файла. Как этому противостоять? Сканируем MFT в поисках записей, помеченных как удаленные, но еще не затертых. Декодируем списки отрезков и вычеркиваем соответствующие им фрагменты из списка кандидатов на восстановление. Это существенно сужает круг поиска, хотя количество комбинаций, в которые можно собрать фрагментированный файл, по‑прежнему остается велико. Но это не самое главное.
Самое "интересное" начинается, когда на диск одновременно записываются несколько файлов (например, скачиваемых из интернета), или когда размер некоего файла постепенно увеличивается (это происходит с документами Word при наборе текста), и одновременно с этим на диск записываются другие файлы. Когда к существующему файлу дописывается крошечная порция данных, файловая система находит наименьшую "дыру", затем следующую наименьшую "дыру" и т. д., вплоть до тех пор, пока маленькие "дыры" не исчерпаются. Когда это происходит, наступает черед "дыр" большего размера. В результате файл сильно фрагментируется. Кроме того, файл заполняется не от больших дыр к меньшим, а наоборот (т. е. происходит инверсия стратегии размещения). Таким образом, маленькие фрагменты одного файла перемешиваются с маленькими фрагментами других файлов.
Хуже всего поддаются восстановлению документы, созданные в Microsoft Office. Так происходит, потому что приложение создает большое количество резервных копий редактируемого файла, как в текущем каталоге, так и в каталоге %TEMP%. Разобраться с тем, какой фрагмент какому файлу принадлежит, очень нелегко!
Проще всего восстанавливать ZIP-архивы. Для этого тебе даже не потребуется запускать дисковый редактор. Открой временный файл на запись, сделай seek на размер свободного дискового пространства, закрой файл. А теперь обработай его утилитой pkzipfix.exe (или воспользуйся утилитой ZIP Repair). В "исправленном" файле волшебным образом появятся все уцелевшие ZIP-архивы! Внутренняя структура ZIP-архива такова, что pkzipfix легко распознает даже переупорядоченные блоки, поэтому высокая степень фрагментации ему не помеха.
Проще всего начать с форматирования. Для экспериментов нам потребуется утилита format.com, входящая в стандартный комплект поставки Windows, а также дисковый раздел, не содержащий никакой ценной информации.
"Живой" винчестер лучше не трогать, во всяком случае, до тех пор, пока ты не научишься его восстанавливать.
При выполнении команды format X: /U /FS:NTFS в файловой системе диска X: происходят следующие изменения (форматирование диска утилитой GUI, вызываемой из контекстного меню "проводника", осуществляется по аналогичной схеме):
Во‑первых, это выбор носителя, на который будут извлекаться восстанавливаемые данные. Запись на оптические накопители отпадает сразу же, так как количество носителей, потребное для сохранения содержимого жесткого диска объемом в терабайты, неприемлемо велико, да и сама технология пишущих оптических приводов сегодня фактически ушла в прошлое. Наконец, ни одна из известных мне утилит автоматического восстановления данных не позволяет "разрезать" большие файлы на несколько маленьких. Если в твоем распоряжении есть локальная сеть, можно перегнать данные по ней. Однако самый простой вариант — подключение внешнего жесткого диска, карты памяти или флеш‑накопителя. Для извлечения пары сотен особо ценных файлов такая методика вполне подходит.
Продемонстрируем технику автоматического восстановления данных на примере утилиты R-Studio от компании R-Tools Technology. Это довольно мощный и в тоже время простой в управлении инструмент, на который можно положиться. После запуска утилиты на экране появится окно Панель дисков, где перечислены все физические устройства и логические разделы. Найди среди них тот, который требуется восстановить, и, нажав правую кнопку мыши, выбери опцию Сканировать.
Программа предложит указать начальный сектор для сканирования (поле Старт), который по умолчанию равен нулю. Это значение следует оставить без изменений. Размер сканируемой области (поле Размер) по умолчанию развертывается на весь раздел. Это гарантирует, что сканер обнаружит все уцелевшие файловые записи, хотя сам поиск займет значительное время. Можно ли ускорить этот процесс? Давай возьмем ручку и подсчитаем. Предположим, что восстанавливаемый раздел содержит сто тысяч файлов. Типичный размер файловой записи составляет 1 Кбайт. При условии, что файл $MFT не фрагментирован, достаточно просканировать всего около 100 Мбайт от начала раздела. Если эта величина (размер пространства, зарезервированного под MFT) не превышает 10% от полной емкости тома и диск никогда не заполнялся более чем на 90%, то, скорее всего, все так и есть.
В противном случае файл $MFT фрагментирован и "живописно" разбросан по всему диску. Впрочем, в случае ошибки мы ничем не рискуем. Вводим значение N Кбайт, где N — предполагаемое количество файлов (каталог также считается файлом), и выполняем сканирование. Если один или несколько файлов останутся необнаруженными, возвращаемся к настройкам по умолчанию и повторяем процедуру сканирования вновь (если количество имеющихся файлов заранее неизвестно, следует указать значение, равное 10% от емкости тома). В поле Файловая система выбираем файловую систему NTFS (можно оставить настройки по умолчанию, файловую систему диска программа определяет корректно). Затем нажмите кнопку Сканирование и сканирование начнется.
В процессе сканирования будут найдены все уцелевшие файлы (как удаленные, так и нет). Кроме того, будет восстановлена структура каталогов, включая и корневой каталог. Постойте! Как же так? Ведь, как ты помнишь, при форматировании корневой каталог был уничтожен и сформирован заново! Но ничего удивительного в этом нет. Просто файловая система NTFS еще раз доказала свою живучесть — уничтожить ее можно, скорее всего, только динамитом. В отличие от FAT, в NTFS каталоги являются лишь вспомогательной структурой данных, проиндексированной для ускорения отображения их содержимого. Всякая файловая запись, независимо от своего происхождения, содержит ссылку на родительский каталог, представляющую собой номер записи в MFT. А запись корневого каталога всегда располагается по одному и тому же адресу!
Удаленные файловые записи могут ссылаться на уже уничтоженные каталоги. R-Studio собирает их в папку $$$FolderXXX, где XXX — порядковый номер каталога. Поэтому иерархия подкаталогов в большинстве случаев успешно восстанавливается.
Просмотр виртуального дерева обнаруженных файлов осуществляется нажатием кнопки F5 или с помощью соответствующей команды контекстного меню. Выбрав файл (или даже целый каталог с большим количеством вложенных подкаталогов), нажми клавишу F2. При желании можно выполнить предварительный просмотр или редактирование (выбрав из контекстного меню пункт Показать содержимое диска). Это достаточно мощный инструмент, отображающий содержимое восстанавливаемого файла со всеми его атрибутами, списками отрезков и т. д. в удобочитаемом формате. При желании можно восстановить все файлы за одну операцию (Восстановить все) или выбрать восстановление по маске.
В процессе форматирования происходит необратимое разрушение большого количества ключевых структур данных, восстанавливать которые вручную было бы слишком затруднительно. К счастью, для извлечения особо ценных файлов этого и не требуется! Идея состоит в том, чтобы вернуть разделу потерянные файловые записи, а все остальные восстановительные операции поручить утилите chkdsk.
Дизассемблирование показывает, что единственной структурой данных, без которой не может работать chkdsk, является атрибут $DATA файла $MFT. А раз так, все, что требуется сделать, сводится к воссозданию прежнего файла $MFT:$DATA и его размещению поверх старых файловых записей. В простейшем случае, если файл $MFT:$DATA не фрагментирован, это достигается так называемым спекулятивным увеличением его длины. Как это сделать?
Запускаем DiskExplorer, переходим в начало MFT (Goto | Mft), выделяем файл $MFT, находим атрибут $DATA (80h) и увеличиваем поля Allocated Size, Real Size и Compressed Size на требуемую величину, параллельно с этим корректируя список отрезков. Поле Last VCN трогать не нужно, так как оно будет исправлено утилитой chkdsk. Как определить длину нефрагментированного файла MFT? Она равна разнице номеров первого и последнего секторов, в начале которых присутствует сигнатура FILE, умноженной на 512 байтов (исключая сектора, принадлежащие $MFTMirr). Известные мне дисковые редакторы не поддерживают поиска последнего вхождения, поэтому соответствующую утилиту приходится писать самостоятельно. К счастью, точную длину MFT определять совершенно не обязательно, и вполне допустимо взять ее с запасом, так как лишнее все равно отсеет chkdsk. Действуй по принципу — лучше перебрать, чем недобрать.
Утилита DiskExplorer не позволяет редактировать поля в естественном режиме отображения, заставляя нас переключаться в HEX-mode и искать смещения всех значений самостоятельно. Найти заголовок атрибута $DATA очень просто — в его начале расположена последовательность 80 00 00 00 xx 00 00 00 01. Поле Real Size во всех версиях NTFS располагается по смещению 30h относительно заголовка, а поля Allocated Size и Initialized Size, соответственно, по смещениям 28h и 38h байтов, причем значение Allocated Size должно быть кратно размеру кластера. Убедись, что при переформатировании диска размер кластера не изменился, в противном случае у вас ничего не получится.
Как восстановить исходный размер кластера? Да очень просто — набраться мужества и переформатировать восстанавливаемый диск с ключом /A:x, где x — размер кластера. А как его определить? Возьмем любой файл с известным содержимым и проанализируем его список отрезков. Запускаем контекстный поиск по всему диску, находим файл, запоминаем (записываем на бумажке) его стартовый сектор, после чего открываем закрепленную за ним файловую запись, декодируем список отрезков и вычисляем номер первого кластера. Делим номер сектора на номер кластера и получаем искомую величину.
Теперь необходимо сгенерировать новый список отрезков. В общем виде он будет выглядеть так: 13 XX XX XX YY 00, где XX XX XX — трехбайтовое значение размера $MFT в кластерах, а YY — стартовый кластер. Стартовый кластер обязательно должен указывать на первый кластер MFT, в противном случае chkdsk не сможет работать. Если новый список отрезков длиннее нынешнего (скорее всего, именно так и будет), то необходимо скорректировать длину атрибутного заголовка (она расположена по смещению 04h от его начала). Проделав эту нехитрую операцию, запустим chkdsk с ключом /F и блаженно откинемся на спинку кресла, созерцая, как возрождаются наши милые папки и файлы.
Единственное, что не восстанавливается — так это дескрипторы безопасности. Всем файлам и папкам будут назначены права доступа по умолчанию. Во всех остальных отношениях с отремонтированным таким образом диском вполне можно будет работать, не опасаясь, что он рухнет окончательно. Файлы, ссылающиеся на несуществующие каталоги, складываются в папку Found.xxx. Это — "долгожители", пережившие несколько циклов переформатирования, в буквальном смысле вытащенные из небытия.
Сложнее восстановить том, MFT которого сильно фрагментирована. Прежний список отрезков при форматировании был уничтожен, зеркальная копия также пострадала. Ничего другого не остается, как собирать все фрагменты руками. К счастью, на практике это оказывается не так сложно, как может показаться на первый взгляд. В отличие от всех остальных файлов диска, файл $MFT имеет замечательную сигнатуру FILE, присутствующую в начале каждой файловой записи. Поэтому все, что нам требуется сделать, сводится к следующим операциям. Последовательно сканируя раздел от первого кластера до последнего, выпишите начало и конец каждого из фрагментов, принадлежащих MFT. Затем из этой цепочки необходимо исключить файл $MFTMirr. Его легко узнать, так как он расположен в середине раздела и содержит копии файловых записей $MFT, $MFTMirr, $LogFile и $Volume, причем $MFTMirr ссылается на себя. В рассматриваемом примере наш список выглядит так: 08h — 333h, 669h — 966h, 1013 — 3210h. В грубом приближении ему будет соответствовать следующий список отрезков: 2 2B 03 08 22 23 03 69 96 22 FD 21 13 10 00.
"В грубом приближении" сказано потому, что мы не знаем, в какой последовательности располагались эти отрезки в файле (порядок расположения фрагментов на диске далеко не всегда совпадает с порядком отрезков в списке отрезков). Что произойдет, если порядок сборки файла $MFT окажется нарушен? Внутри MFT все файловые записи ссылаются друг на друга по своим порядковым номерам, представляющим собой индексы массива. Эти ссылки необходимы для восстановления структуры каталогов, организации жестких ссылок (hard links) и еще некоторых служебных структур. Ссылки на родительский каталог дублируются в индексах и восстанавливаются элементарно. Жесткие ссылки теряются безвозвратно (единственный способ восстановить их заключается в повторении попытки сборки файла $MFT в другом порядке). Однако они практически нигде и никак не используются, так что их потеря не столь уж существенна. По‑настоящему туго приходится сильно фрагментированным файлам, занимающим несколько файловых записей, раскиданных по разным фрагментам $MFT. Здесь выручает только перестановка фрагментов. К счастью, количество комбинаций обычно бывает невелико, и процедура восстановления занимает совсем немного времени. Хорошая новость — начиная с NTFS версии 3.1, в MFT номера файловых записей хранятся в явном виде (четырехбайтовое поле, расположенное по смещению 2Ch от начала файловой записи), что делает задачу восстановления тривиальной.
ПАКЕТ FILE_DISPOSITION_INFORMATION
IRP_MJ_SET_INFORMATION/FILE_DISPOSITION_INFORMATION — это пакеты, посылаемые драйверу при удалении файла (имей это в виду при дизассемблировании). Чтобы уметь восстанавливать удаленные файлы, необходимо отчетливо представлять, что происходит в процессе удаления файла с раздела NTFS. Вот последовательность выполняемых при этом действий.- Корректируется файл /$MFT:$BITMAP, каждый бит которого определяет "занятость" соответствующей файловой записи (FILE Record) в MFT (значение 0 говорит о том, что запись не используется).
- Корректируется файл /$BITMAP, каждый бит которого определяет "занятость" соответствующего кластера (значение 0 говорит о том, что кластер не используется).
- Файловые записи, соответствующие файлу, помечаются как удаленные (поле FLAG, находящееся по смещению 16h от начала файловой записи, сбрасывается в нуль).
- Ссылка на файл удаляется из двоичного дерева индексов. Технические подробности этого процесса здесь не рассматриваются, поскольку восстановить таблицу индексов вручную сможет только "гуру". Кроме того, в таком восстановлении нет необходимости. Ведь в NTFS индексы играют вспомогательную роль, и гораздо проще переиндексировать каталог заново, чем восстанавливать сбалансированное двоичное дерево (B-tree).
- Обновляется атрибут $STANDART_INFORMATION каталога, в котором хранится удаляемый файл (время последнего доступа и т. д.).
- В файле /$LogFile обновляется поле Sequence Number (изменения, происходящие в журнале транзакций, здесь не рассматриваются).
- Поля Update Sequence Number следующих файловых записей увеличиваются на единицу: сам удаляемый файл, текущий каталог, $MFT, /$MFT:$BITMAP, /$BITMAP, /$BOOT, /$TRACKING.LOG.
Ни в том, ни в другом случае физического удаления файла не происходит, и он может быть легко восстановлен. Легкое и быстрое восстановление возможно до тех пор, пока не будет затерта файловая запись (FILE Record), принадлежащая этому файлу и хранящая его резидентное тело или список отрезков (run-list) нерезидентного содержимого. Утрата файловой записи крайне неприятна, поскольку в этом случае файл придется собирать по кластерам. При этом стоит заметить, что чем сильнее был фрагментирован удаленный файл, тем сложнее будет эта задача. К счастью, в отличие от FAT, NTFS не затирает первого символа имени файла, что значительно упрощает восстановление.
АВТОМАТИЧЕСКОЕ ВОССТАНОВЛЕНИЕ УДАЛЕННЫХ ФАЙЛОВ
Утилиты, восстанавливающие удаленные файлы, не входят в стандартный комплект поставки Windows. Разумеется, это явный недостаток — вспомни, ведь в MS-DOS такая утилита была! Следовательно, эти средства приходится приобретать отдельно. Одна из автоматических утилит для восстановления удаленных файлов — GetDataBack. Опасаясь разрушить файловую систему окончательно, большинство таких утилит избегает прямой записи на диск. Вместо этого пользователю предлагается считать удаленный файл и переписать его в другое место, но только не на сам восстанавливаемый раздел. Не слишком‑то удачное решение. А если на остальных дисках свободного места нет, или если восстанавливаемый диск имеет всего лишь один логический раздел?Предположим, нам необходимо восстановить базу данных объемом в несколько гигабайт. Можно, конечно, подключить второй винчестер, скопировать ее туда, а затем обратно. Однако подумай, сколько же это займет времени, не говоря уже о том, что сервер лучше не выключать, а "горячую" замену поддерживают далеко не все жесткие диски!
Другой недостаток подобных утилит — слишком медленная работа. Вместо того чтобы найти один‑единственный файл, имя которого нам известно, они проводят полномасштабные "маневры", сканируя весь раздел целиком. При работе с большими дисками на это уходит от одного до нескольких часов, причем это время фактически тратится впустую.
С другой стороны, утилиты, вносящие изменения непосредственно в структуру NTFS, рискуют серьезно повредить дисковый том, после чего ему не помогут даже профессионалы. Настоящие хакеры не доверяют никакому коду, кроме созданного лично ими, особенно, если исходные тексты недоступны, а документация туманна и двусмысленна. Различные версии NTFS отличаются друг от друга. Последние радикальные изменения произошли в Windows XP (NTFS версии 3.1) — массив последовательностей обновления (Update Sequence Number-n-Array) переместился на шесть байтов вперед, а его место было отдано под выравнивание и поле номера текущей файловой записи (Number of this MFT Record). С тех пор формат файловой системы не претерпел каких‑либо существенных архитектурных изменений.
Наконец, возможна и такая ситуация, когда утилит восстановления просто не окажется под рукой в тот момент, когда вам срочно потребуется восстановить какой‑нибудь ценный файл. Законов Мэрфи еще никто не отменял! В этом случае вам придется рассчитывать только на свои силы.
РУЧНОЕ ВОССТАНОВЛЕНИЕ ОШИБОЧНО УДАЛЕННЫХ ФАЙЛОВ
Начнем с простейшего. Файл только что удален, и принадлежащая ему файловая запись еще не затерта. Как найти его на диске? Существует два способа — "теоретический" и "практический". Теоретический метод исключительно надежен, но требует дополнительных операций, выполнения которых можно избежать, приняв ряд практических допущений.Теоретически грамотный и правильный подход состоит в следующем. Извлекаем из загрузочного сектора указатель на MFT, извлекаем из нее первую запись (она описывает $MFT), находим атрибут $DATA (80h), декодируем список отрезков (data runs) и последовательно читаем все записи в MFT, анализируя содержимое атрибута $FILE_NAME (30h) — имя файла. Обрати внимание, что таких атрибутов у файла может быть несколько. Этот же атрибут хранит ссылку на родительский каталог. Поэтому, если несколько одноименных файлов были удалены из различных каталогов, то необходимо выяснить, какой именно из них должен быть восстановлен.
Практический подход выглядит следующим образом. В девяти случаях из десяти файл $MFT не фрагментирован и располагается в самом начале диска. Имена файлов хранятся по смещению EAh от начала сектора, в начале которого расположена сигнатура FILE0. Поэтому можно просто запустить любой дисковый редактор, ввести имя восстанавливаемого файла в кодировке UNICODE и дать редактору указание искать его по смещению F0h от начала сектора.
Когда же искомая строка будет найдена, необходимо проверить, находится ли в начале сектора сигнатура FILE0. Если такой сигнатуры в начале сектора нет, следует продолжить поиск. Двухбайтовое поле по смещению 16h от начала сектора содержит флаги записи: 00h — запись не используется или была удалена, 01h — запись используется, 02h — запись используется и описывает каталог. Встречаются и другие значения, например, 04h, 08h. Эти значения не документированы. Возможно, что именно ты сможешь пролить свет на этот вопрос?
Исправляем 00h на 01h, записываем изменения и… Ничего не выходит?! А что же ты хотел! Ведь помимо этого необходимо выполнить еще несколько действий. Во‑первых, следует сообщить файлу /$MFT:$BITMAP, что данная запись MFT вновь используется. Во‑вторых, необходимо исключить из файла /$BITMAP номера кластеров, принадлежащие восстанавливаемому файлу. Наконец, необходимо перестроить двоичное дерево индексов, хранящее содержимое каталога.
Первые два пункта не представляют серьезной проблемы, но вот над последней задачей придется повозиться. Хотя ее можно существенно упростить, просто запустив chkdsk с ключом /F. Утилита chkdsk самостоятельно найдет "потерянный" файл и внесет все необходимые изменения в файловую систему. От вас потребуется только установить флаг по смещению 16h в единицу, а все остальное сделает chkdsk. После этих нехитрых манипуляций восстановленный файл окажется в своем родном каталоге.
INFO
В Windows 10 утилиту chkdsk можно запустить из командной строки (cmd.exe) или из консоли PowerShell. Помни, что выполнение chkdsk требует наличия системных привилегий, поэтому консоль следует запускать от имени Администратора. Если ты пытаешься выполнить проверку системного раздела, на котором располагается текущая версия ОС, программа не сможет проверить диск, так как том окажется заблокированным. В этом случае тебе будет предложено выполнить проверку при следующей загрузке Windows.ВОССТАНАВЛИВАЕМ РУИНЫ
Рассмотрим более сложный случай восстановления, а именно — ситуацию, когда файловая запись уже затерта. Если удаленный файл был резидентным (хранил свое тело в MFT), то восстанавливать уже нечего. Даже если на ранее занимаемом им месте создан нерезидентный файл (а файловая запись нерезидентного файла заканчивается там, где начинается резидентное тело), операционная система заботливо заполнит оставшийся "хвост" нулями, и для восстановления оригинального содержимого придется прибегнуть к дорогостоящему оборудованию, читающему поверхность жесткого диска на физическом уровне.С нерезидентными файлами, хранящими свое тело вне MFT, ситуация обстоит не так плачевно, хотя и здесь проблем тоже хватает. Порядок размещения файла на диске хранится в списке отрезков (run-list) внутри файловой записи в MFT. При этом, поскольку файловая запись уже затерта, возможен лишь контекстный поиск по содержимому. Запускаем дисковый редактор, вводим последовательность, заведомо содержащуюся в удаленном файле, но не встречающуюся во всех остальных, и даем редактору команду начать поиск. Для ускорения поиска можно искать только в свободном дисковом пространстве (за это отвечает файл /$BITMAP).
Восстановление нефрагментированных файлов осуществляется элементарно. Достаточно просто выделить группу секторов и записать ее содержимое на диск.
WARNING
Повторяю еще раз — ни в коем случае не записывай файлы на сам восстанавливаемый том!Единственная проблема заключается в определении оригинальной длины. Некоторые типы файлов допускают присутствие "мусора" в своем хвосте. В этом случае можно следовать правилу, гласящему, что перебор лучше недобора. Однако это справедливо не для всех файлов! Если конец файла не удается определить визуально (например, pdf-файлы завершаются сигнатурой %%EOF), проанализируй заголовок файла. Как правило, наряду с прочей полезной информацией там присутствует и размер файла. В данном случае все зависит от структуры конкретного файла, и универсальных рекомендаций дать невозможно.
Если восстанавливаемый файл фрагментирован, то ситуация осложняется. По правде говоря, она практически безнадежна, поскольку, чтобы собрать разрозненные цепочки кластеров воедино, необходимо хорошо знать содержимое удаленного файла. В этом смысле NTFS восстанавливается намного хуже, чем FAT. Последовательность фрагментов файла, хранящаяся в FAT в виде однонаправленного списка, очень живуча. Если список не поврежден, достаточно лишь найти его первый элемент (а сделать это проще простого, поскольку он будет указывать на заголовок файла с вполне предсказуемым содержимым). Даже если список "разрубить" на несколько частей, они продолжат жить собственной жизнью, и останется лишь подобрать комбинацию, в которой их необходимо склеить воедино. Список гибнет лишь при полном затирании FAT, что случается, прямо скажем, не часто.
В NTFS же порядок фрагментов файла хранится в крохотных списках отрезков, и их гибель — обычное дело, после чего мы остаемся один на один с миллионом беспорядочно разбросанных кластеров. С текстовыми файлами еще можно работать, но что делать, если файл представлял собой электронную таблицу, графическое изображение или архив? Без знания стратегии выделения дискового пространства восстановить такой файл невозможно. Порядок, в котором драйвер файловой системы находит подходящие свободные фрагменты, не предопределен. Он варьируется в зависимости от множества обстоятельств, однако некоторые закономерности в нем все же присутствуют.
В ходе анализа списков отрезков сильно фрагментированных дисков мне удалось установить следующие закономерности. Сначала заполняются самые большие "дыры", причем заполнение происходит в направлении от конца зоны MFT к концу диска. Затем драйвер файловой системы возвращается назад и начинает заполнять "дыры" поменьше. Так продолжается до тех пор, пока файл не оказывается на диске целиком. В последнюю очередь заполняются "дыры" размером в один кластер.
Просматривая карту диска, представленную файлом /$BITMAP, мы можем в точности восстановить порядок размещения фрагментов удаленного файла, наскоро собрав их воедино. Во всяком случае, теоретически такая возможность существует. На практике же на этом пути нас ждут коварные препятствия. Дело в том, что с момента создания восстанавливаемого файла карта свободного дискового пространства могла радикально измениться. Всякая операция удаления файлов высвобождает одну или несколько "дыр", хаотично перемешивающихся с "дырами" восстанавливаемого файла. Как этому противостоять? Сканируем MFT в поисках записей, помеченных как удаленные, но еще не затертых. Декодируем списки отрезков и вычеркиваем соответствующие им фрагменты из списка кандидатов на восстановление. Это существенно сужает круг поиска, хотя количество комбинаций, в которые можно собрать фрагментированный файл, по‑прежнему остается велико. Но это не самое главное.
Самое "интересное" начинается, когда на диск одновременно записываются несколько файлов (например, скачиваемых из интернета), или когда размер некоего файла постепенно увеличивается (это происходит с документами Word при наборе текста), и одновременно с этим на диск записываются другие файлы. Когда к существующему файлу дописывается крошечная порция данных, файловая система находит наименьшую "дыру", затем следующую наименьшую "дыру" и т. д., вплоть до тех пор, пока маленькие "дыры" не исчерпаются. Когда это происходит, наступает черед "дыр" большего размера. В результате файл сильно фрагментируется. Кроме того, файл заполняется не от больших дыр к меньшим, а наоборот (т. е. происходит инверсия стратегии размещения). Таким образом, маленькие фрагменты одного файла перемешиваются с маленькими фрагментами других файлов.
Хуже всего поддаются восстановлению документы, созданные в Microsoft Office. Так происходит, потому что приложение создает большое количество резервных копий редактируемого файла, как в текущем каталоге, так и в каталоге %TEMP%. Разобраться с тем, какой фрагмент какому файлу принадлежит, очень нелегко!
Проще всего восстанавливать ZIP-архивы. Для этого тебе даже не потребуется запускать дисковый редактор. Открой временный файл на запись, сделай seek на размер свободного дискового пространства, закрой файл. А теперь обработай его утилитой pkzipfix.exe (или воспользуйся утилитой ZIP Repair). В "исправленном" файле волшебным образом появятся все уцелевшие ZIP-архивы! Внутренняя структура ZIP-архива такова, что pkzipfix легко распознает даже переупорядоченные блоки, поэтому высокая степень фрагментации ему не помеха.
ВОССТАНОВЛЕНИЕ РАЗДЕЛОВ NTFS ПОСЛЕ ФОРМАТИРОВАНИЯ
Представь себе, что случилось самое страшное: ты потерял весь раздел NTFS целиком. Возможно, ты случайно отформатировал его или пережил разрушительный дисковый сбой. Где‑то там остались миллиарды байтов бесценных данных, теперь уже недоступных операционной системе. Как вернуть информацию к жизни? До сих пор мы рассматривали лишь незначительные дисковые сбои и легкие разрушения данных наподобие ошибочно удаленных файлов. Теперь настал черед рассмотреть восстановление после тяжелых повреждений, при которых прежнее содержимое тома становится недоступно операционной системе. Причиной этому может быть, например, непредумышленное форматирование или искажение главной файловой таблицы. Но не падай духом! Из любых переделок NTFS выходит с минимальными потерями, и во всех этих случаях возможно полное восстановление данных, если к делу подойти правильно.Проще всего начать с форматирования. Для экспериментов нам потребуется утилита format.com, входящая в стандартный комплект поставки Windows, а также дисковый раздел, не содержащий никакой ценной информации.
WARNING
Лучше всего проводить эксперименты на виртуальной машине — VirtualBox или VMWare, эмулирующей жесткий диск и ускоряющей процедуру форматирования в сотни раз. Ведь время — это не только деньги, но и бесцельно прожитые годы, проведенные за созерцанием индикатора прогресса.INFO
Команда format в Windows 10 работает с одной интересной особенностью, которую вполне можно назвать багом: она не позволяет отформатировать том, если пользователь не указал его метку, выдавая ошибку: "указана недопустимая метка диска". Чтобы исправить эту ошибку, сделай следующее. Перейди в Командной строке на диск, который ты хочешь отформатировать, и набери команду vol. В окне Командной строки отобразится информация об имени метки и серийном номере тома. Затем, набрав команду format с именем диска, по запросу программы format.exe введи полученную на предыдущем шаге метку тома. Если том в настоящее время используется, согласись с предложением операционной системы размонтировать его."Живой" винчестер лучше не трогать, во всяком случае, до тех пор, пока ты не научишься его восстанавливать.
Действия, выполняемые при форматировании
Форматирование диска — это сложная многоступенчатая операция, намного более сложная и намного более многоступенчатая, чем это может показаться на первый взгляд. Свои исследования мы начнем с изучения непредумышленно переформатированного тома NTFS.При выполнении команды format X: /U /FS:NTFS в файловой системе диска X: происходят следующие изменения (форматирование диска утилитой GUI, вызываемой из контекстного меню "проводника", осуществляется по аналогичной схеме):
- Формируется загрузочный сектор NTFS.
- Генерируется новый серийный номер тома, который затем записывается в загрузочный сектор по смещению 48h байтов от его начала.
- Рассчитывается новая контрольная сумма загрузочного сектора, которая затем записывается по смещению 50h от его начала. Создается новый файл $MFT, содержащий сведения обо всех файлах на диске. Как правило, он записывается поверх старого файла $MFT. Исключения из этого правила бывают, но они крайне редки. Обычно они происходят, если прежний файл $MFT был заблаговременно перемещен дефрагментатором, или если при переформатировании был назначен новый размер кластера. Во всех остальных случаях первые 24 файловых записи (FILE Record) погибают безвозвратно. Эти записи содержат непосредственно сам файл $MFT, $MFTMirr, корневой каталог, /$LogFile — файл транзакций, /$BITMAP — карту свободного пространства, /$Secure — дескрипторы безопасности, а также ряд других служебных файлов.
- Инициализируется файл $MFT:$DATA — назначаются новая длина файла (инициализируются $MFT:$30.AllocatedSize, $MFT:$30.RealSize, $MFT:$80.AllocatedSize, $MFT:$80.RealSize, $MFT:$80.CompressionSize, $MFT:$80.InitializedSize и $MFT:$80.LastVCN), дата и время создания и последней модификации (инициализируются $MFT:$10.FileCreationTime, $MFT:$10.FileAlertedTime, $MFT:$10.FileReadTime, $MFT:$30.FileCreationTime, $MFT:$30.FileAlertedTime, $MFT:$30.MFTChangeTime и $MFT:$30.FileReadTime) и, самое главное, создается новый список отрезков (data-runs), необратимо затирающий старый. Это значит, что собирать фрагментированный файл $MFT нам придется по частям.
- Создается новый файл /$MFT:$BITMAP, отвечающий за занятость файловых записей в MFT. При этом все старые записи помечаются как свободные, однако их фактического удаления не происходит (поле FileRecord.flags остается нетронутым), благодаря чему процедура восстановления заметно упрощается. Чаще всего $MFT:$BITMAP располагается на том же самом месте, что и старый (т. е. между загрузочным сектором и MFT), забивая прежнее содержимое нулями, однако с помощью утилиты chkdsk его можно восстановить.
- Создается новый файл /$BITMAP, отвечающий за распределение дискового пространства (свободные и занятые кластеры). Этот файл также записывается поверх прежнего файла /$BITMAP, который, тем не менее, может быть восстановлен с помощью chkdsk.
- Создается новый файл журнала транзакций — /$LogFile.
- B заголовок файловой записи $MFT заносится новый LSN (LogFile Sequence Number).
- $MFT назначается новый номер последовательности обновления (Update Sequence Number).
- Создается новое зеркало $MFTMirr, необратимо затирающее старое (в текущих версиях файловых систем оно расположено в середине раздела NTFS).
- Создаются новые /$Volume, /$AttrDef и другие служебные файлы, играющие сугубо вспомогательную роль и легко восстанавливаемые утилитой chkdsk. Следует отметить, что хотя /$Volume и присутствует в зеркальной копии MFT, его ценность явно преувеличена.
- Осуществляется проверка целостности поверхности диска, и все обнаруженные "плохие" кластеры заносятся в файл /$BadClus.
- Формируется новый корневой каталог.
- Если до форматирования тома на нем присутствовал файл /System Volume Information, то он обновляется, в противном случае новый файл /System Volume Information создается только после перезагрузки.
Совет
Утилита format.com содержит лишь высокоуровневую надстройку, опирающуюся на библиотеки fsutil.dll, untfs.dll, и непосредственно на сам драйвер файловой системы. Так что дизассемблировать придется много. Чтобы упросить себе работу, можно пронаблюдать за процессом форматирования с помощью "шпионских" средств, например, утилит Марка Руссиновича Process Monitor (procmon.exe), Diskmon.exe, бесплатные копии которых можно скачать с сайта https://docs.microsoft.com/en-us/sysinternals/. Кроме того, не забывай о точках останова на основные функции native API, такие как NtFsControlFile, NtDeviceIoControlFile и т. д.Автоматическое восстановление диска после форматирования
Форматирование не уничтожает файловые записи пользовательских файлов, и их можно полностью восстановить. Существует множество утилит для восстановления данных, например, R-Studio, EasyRecovery, GetDataBack, и т. д. Тем не менее, прямых наследников утилиты unformat среди них не наблюдается. Утилита unformat.exe восстанавливала весь том целиком, а все перечисленные современные средства всего лишь извлекают отдельные уцелевшие файлы и каталоги, переписывая их на новый носитель. Вот здесь мы сталкиваемся с рядом проблем.Во‑первых, это выбор носителя, на который будут извлекаться восстанавливаемые данные. Запись на оптические накопители отпадает сразу же, так как количество носителей, потребное для сохранения содержимого жесткого диска объемом в терабайты, неприемлемо велико, да и сама технология пишущих оптических приводов сегодня фактически ушла в прошлое. Наконец, ни одна из известных мне утилит автоматического восстановления данных не позволяет "разрезать" большие файлы на несколько маленьких. Если в твоем распоряжении есть локальная сеть, можно перегнать данные по ней. Однако самый простой вариант — подключение внешнего жесткого диска, карты памяти или флеш‑накопителя. Для извлечения пары сотен особо ценных файлов такая методика вполне подходит.
Продемонстрируем технику автоматического восстановления данных на примере утилиты R-Studio от компании R-Tools Technology. Это довольно мощный и в тоже время простой в управлении инструмент, на который можно положиться. После запуска утилиты на экране появится окно Панель дисков, где перечислены все физические устройства и логические разделы. Найди среди них тот, который требуется восстановить, и, нажав правую кнопку мыши, выбери опцию Сканировать.
Программа предложит указать начальный сектор для сканирования (поле Старт), который по умолчанию равен нулю. Это значение следует оставить без изменений. Размер сканируемой области (поле Размер) по умолчанию развертывается на весь раздел. Это гарантирует, что сканер обнаружит все уцелевшие файловые записи, хотя сам поиск займет значительное время. Можно ли ускорить этот процесс? Давай возьмем ручку и подсчитаем. Предположим, что восстанавливаемый раздел содержит сто тысяч файлов. Типичный размер файловой записи составляет 1 Кбайт. При условии, что файл $MFT не фрагментирован, достаточно просканировать всего около 100 Мбайт от начала раздела. Если эта величина (размер пространства, зарезервированного под MFT) не превышает 10% от полной емкости тома и диск никогда не заполнялся более чем на 90%, то, скорее всего, все так и есть.
В противном случае файл $MFT фрагментирован и "живописно" разбросан по всему диску. Впрочем, в случае ошибки мы ничем не рискуем. Вводим значение N Кбайт, где N — предполагаемое количество файлов (каталог также считается файлом), и выполняем сканирование. Если один или несколько файлов останутся необнаруженными, возвращаемся к настройкам по умолчанию и повторяем процедуру сканирования вновь (если количество имеющихся файлов заранее неизвестно, следует указать значение, равное 10% от емкости тома). В поле Файловая система выбираем файловую систему NTFS (можно оставить настройки по умолчанию, файловую систему диска программа определяет корректно). Затем нажмите кнопку Сканирование и сканирование начнется.
В процессе сканирования будут найдены все уцелевшие файлы (как удаленные, так и нет). Кроме того, будет восстановлена структура каталогов, включая и корневой каталог. Постойте! Как же так? Ведь, как ты помнишь, при форматировании корневой каталог был уничтожен и сформирован заново! Но ничего удивительного в этом нет. Просто файловая система NTFS еще раз доказала свою живучесть — уничтожить ее можно, скорее всего, только динамитом. В отличие от FAT, в NTFS каталоги являются лишь вспомогательной структурой данных, проиндексированной для ускорения отображения их содержимого. Всякая файловая запись, независимо от своего происхождения, содержит ссылку на родительский каталог, представляющую собой номер записи в MFT. А запись корневого каталога всегда располагается по одному и тому же адресу!
Удаленные файловые записи могут ссылаться на уже уничтоженные каталоги. R-Studio собирает их в папку $$$FolderXXX, где XXX — порядковый номер каталога. Поэтому иерархия подкаталогов в большинстве случаев успешно восстанавливается.
Просмотр виртуального дерева обнаруженных файлов осуществляется нажатием кнопки F5 или с помощью соответствующей команды контекстного меню. Выбрав файл (или даже целый каталог с большим количеством вложенных подкаталогов), нажми клавишу F2. При желании можно выполнить предварительный просмотр или редактирование (выбрав из контекстного меню пункт Показать содержимое диска). Это достаточно мощный инструмент, отображающий содержимое восстанавливаемого файла со всеми его атрибутами, списками отрезков и т. д. в удобочитаемом формате. При желании можно восстановить все файлы за одну операцию (Восстановить все) или выбрать восстановление по маске.
Ручное восстановление жесткого диска после форматирования
Нашей целью будет ручное восстановление всего отформатированного раздела без использования дополнительных носителей информации и дорогостоящих утилит от сторонних производителей. Все что для этого потребуется — любой редактор диска (предпочтительнее всего, конечно же, DiskExplorer от Runtime Software) в комбинации со встроенной утилитой chkdsk.В процессе форматирования происходит необратимое разрушение большого количества ключевых структур данных, восстанавливать которые вручную было бы слишком затруднительно. К счастью, для извлечения особо ценных файлов этого и не требуется! Идея состоит в том, чтобы вернуть разделу потерянные файловые записи, а все остальные восстановительные операции поручить утилите chkdsk.
Дизассемблирование показывает, что единственной структурой данных, без которой не может работать chkdsk, является атрибут $DATA файла $MFT. А раз так, все, что требуется сделать, сводится к воссозданию прежнего файла $MFT:$DATA и его размещению поверх старых файловых записей. В простейшем случае, если файл $MFT:$DATA не фрагментирован, это достигается так называемым спекулятивным увеличением его длины. Как это сделать?
Запускаем DiskExplorer, переходим в начало MFT (Goto | Mft), выделяем файл $MFT, находим атрибут $DATA (80h) и увеличиваем поля Allocated Size, Real Size и Compressed Size на требуемую величину, параллельно с этим корректируя список отрезков. Поле Last VCN трогать не нужно, так как оно будет исправлено утилитой chkdsk. Как определить длину нефрагментированного файла MFT? Она равна разнице номеров первого и последнего секторов, в начале которых присутствует сигнатура FILE, умноженной на 512 байтов (исключая сектора, принадлежащие $MFTMirr). Известные мне дисковые редакторы не поддерживают поиска последнего вхождения, поэтому соответствующую утилиту приходится писать самостоятельно. К счастью, точную длину MFT определять совершенно не обязательно, и вполне допустимо взять ее с запасом, так как лишнее все равно отсеет chkdsk. Действуй по принципу — лучше перебрать, чем недобрать.
Утилита DiskExplorer не позволяет редактировать поля в естественном режиме отображения, заставляя нас переключаться в HEX-mode и искать смещения всех значений самостоятельно. Найти заголовок атрибута $DATA очень просто — в его начале расположена последовательность 80 00 00 00 xx 00 00 00 01. Поле Real Size во всех версиях NTFS располагается по смещению 30h относительно заголовка, а поля Allocated Size и Initialized Size, соответственно, по смещениям 28h и 38h байтов, причем значение Allocated Size должно быть кратно размеру кластера. Убедись, что при переформатировании диска размер кластера не изменился, в противном случае у вас ничего не получится.
Как восстановить исходный размер кластера? Да очень просто — набраться мужества и переформатировать восстанавливаемый диск с ключом /A:x, где x — размер кластера. А как его определить? Возьмем любой файл с известным содержимым и проанализируем его список отрезков. Запускаем контекстный поиск по всему диску, находим файл, запоминаем (записываем на бумажке) его стартовый сектор, после чего открываем закрепленную за ним файловую запись, декодируем список отрезков и вычисляем номер первого кластера. Делим номер сектора на номер кластера и получаем искомую величину.
Теперь необходимо сгенерировать новый список отрезков. В общем виде он будет выглядеть так: 13 XX XX XX YY 00, где XX XX XX — трехбайтовое значение размера $MFT в кластерах, а YY — стартовый кластер. Стартовый кластер обязательно должен указывать на первый кластер MFT, в противном случае chkdsk не сможет работать. Если новый список отрезков длиннее нынешнего (скорее всего, именно так и будет), то необходимо скорректировать длину атрибутного заголовка (она расположена по смещению 04h от его начала). Проделав эту нехитрую операцию, запустим chkdsk с ключом /F и блаженно откинемся на спинку кресла, созерцая, как возрождаются наши милые папки и файлы.
Единственное, что не восстанавливается — так это дескрипторы безопасности. Всем файлам и папкам будут назначены права доступа по умолчанию. Во всех остальных отношениях с отремонтированным таким образом диском вполне можно будет работать, не опасаясь, что он рухнет окончательно. Файлы, ссылающиеся на несуществующие каталоги, складываются в папку Found.xxx. Это — "долгожители", пережившие несколько циклов переформатирования, в буквальном смысле вытащенные из небытия.
Сложнее восстановить том, MFT которого сильно фрагментирована. Прежний список отрезков при форматировании был уничтожен, зеркальная копия также пострадала. Ничего другого не остается, как собирать все фрагменты руками. К счастью, на практике это оказывается не так сложно, как может показаться на первый взгляд. В отличие от всех остальных файлов диска, файл $MFT имеет замечательную сигнатуру FILE, присутствующую в начале каждой файловой записи. Поэтому все, что нам требуется сделать, сводится к следующим операциям. Последовательно сканируя раздел от первого кластера до последнего, выпишите начало и конец каждого из фрагментов, принадлежащих MFT. Затем из этой цепочки необходимо исключить файл $MFTMirr. Его легко узнать, так как он расположен в середине раздела и содержит копии файловых записей $MFT, $MFTMirr, $LogFile и $Volume, причем $MFTMirr ссылается на себя. В рассматриваемом примере наш список выглядит так: 08h — 333h, 669h — 966h, 1013 — 3210h. В грубом приближении ему будет соответствовать следующий список отрезков: 2 2B 03 08 22 23 03 69 96 22 FD 21 13 10 00.
"В грубом приближении" сказано потому, что мы не знаем, в какой последовательности располагались эти отрезки в файле (порядок расположения фрагментов на диске далеко не всегда совпадает с порядком отрезков в списке отрезков). Что произойдет, если порядок сборки файла $MFT окажется нарушен? Внутри MFT все файловые записи ссылаются друг на друга по своим порядковым номерам, представляющим собой индексы массива. Эти ссылки необходимы для восстановления структуры каталогов, организации жестких ссылок (hard links) и еще некоторых служебных структур. Ссылки на родительский каталог дублируются в индексах и восстанавливаются элементарно. Жесткие ссылки теряются безвозвратно (единственный способ восстановить их заключается в повторении попытки сборки файла $MFT в другом порядке). Однако они практически нигде и никак не используются, так что их потеря не столь уж существенна. По‑настоящему туго приходится сильно фрагментированным файлам, занимающим несколько файловых записей, раскиданных по разным фрагментам $MFT. Здесь выручает только перестановка фрагментов. К счастью, количество комбинаций обычно бывает невелико, и процедура восстановления занимает совсем немного времени. Хорошая новость — начиная с NTFS версии 3.1, в MFT номера файловых записей хранятся в явном виде (четырехбайтовое поле, расположенное по смещению 2Ch от начала файловой записи), что делает задачу восстановления тривиальной.
