Текст книги "Восстановление данных. Практическое руководство"
Автор книги: Крис Касперски
Жанры:
Компьютерное "железо"
,сообщить о нарушении
Текущая страница: 14 (всего у книги 26 страниц)
Форматирование не уничтожает файловые записи пользовательских файлов, и они могут быть полностью восстановлены. Существует множество утилит для восстановления данных, например, R-Studio, EasyRecovery, GetDataBack, и т.д. Тем не менее, прямых наследников утилиты unformat среди них не наблюдается. Утилита unformat.exe восстанавливала весь том целиком, а все перечисленные выше современные средства всего лишь извлекают отдельные уцелевшие файлы и каталоги, переписывая их на новый носитель. Вот здесь мы сталкиваемся с рядом проблем. Во-первых, это выбор носителя, на который будут извлекаться восстанавливаемые данные. Запись на оптические накопители отпадает сразу же. так как количество носителей, потребное для сохранения содержимого жесткого диска объемом 80–120 Гбайт, неприемлемо велико. Кроме того, непосредственная запись CD-R/RW не всегда возможна, ведь при крахе системы восстанавливающие утилиты приходится загружать с CD-ROM, а в большинстве компьютеров установлен только один оптический привод. Наконец, ни одна из известных мне утилит автоматического восстановления данных не позволяет "разрезать" большие файлы на несколько маленьких. Если в вашем распоряжении есть локальная сеть, можно перегнать данные по ней. Еще один вариант – установка дополнительного жесткого диска (при условии наличия свободных каналов контроллера). Выбирая этот подход, следует иметь в виду, что, если корпус компьютера опечатан, то его вскрытие автоматически лишает вас гарантии. То есть вам в любом случае не обойтись без определенных финансовых затрат. Тем не менее, для извлечения пары сотен особо ценных файлов такая методика вполне подходит.
Продемонстрируем технику автоматического восстановления данных на примере утилиты R-Studio от компании R-TT Inc. (http://www.r-tt.com). Это – довольно мощный и в тоже время простой в управлении инструмент, на который можно положиться. После запуска утилиты на экране появится окно Drive View, где перечислены все физические устройства и логические разделы. Найдите среди них тот, который требуется восстановить, и, нажав правую кнопку мыши, выберите опцию Scan.
Программа предложит указать начальный сектор для сканирования (поле Start), который по умолчанию равен 0. Это значение следует оставить без изменений. Размер сканируемой области (поле Size) по умолчанию развертывается на весь раздел. Это гарантирует, что сканер обнаружит все уцелевшие файловые записи, хотя сам поиск займет значительное время. Можно ли ускорить этот процесс? Давайте возьмем ручку и подсчитаем. Предположим, что восстанавливаемый раздел содержит сто тысяч файлов. Типичный размер файловой записи составляет 1 Кбайт. При условии, что файл $MFT не фрагментирован, достаточно просканировать всего около 100 Мбайт от начала раздела. Если эта величина (размер пространства, зарезервированного под MFT) не превышает 10% от полной емкости тома и диск никогда не заполнялся более чем на 90%, то, скорее всего, все так и есть. В противном случае файл $MFT фрагментирован и живописно разбросан по всему диску. Впрочем, в случае ошибки мы ничем не рискуем. Вводим значение N Кбайт, где N – предполагаемое количество файлов (каталог также считается файлом), и выполняем сканирование. Если один или несколько файлов останутся необнаруженными, возвращаемся к настройкам по умолчанию и повторяем процедуру сканирования вновь (если количество имеющихся файлов заранее неизвестно, следует указать значение, равное 10% от емкости тома). В поле File System выбираем файловую систему NTFS, сбрасывая флажки напротив двух других доступных опций (FAT и Ext2fs). Затем нажмите кнопку Scan и сканирование начнется (рис. 7.7).
Рис. 7.7. R-Studio осуществляет поиск уцелевших файловых записей
В процессе сканирования будут найдены все уцелевшие файлы (как удаленные, так и нет). Кроме того, будет восстановлена структура каталогов, включая и корневой каталог (рис. 7.8). Постойте! Как же так? Ведь, как вы помните, при форматировании корневой каталог был уничтожен и сформирован заново! Но ничего удивительного в этом нет. Просто файловая система NTFS еще раз доказала свою живучесть – уничтожить ее можно, скорее всего, только динамитом. В отличие от FAT, в NTFS каталоги являются лишь вспомогательной структурой данных, проиндексированной для ускорения отображения их содержимого. Всякая файловая запись, независимо от своего происхождения, содержит ссылку на родительский каталог, представляющую собой номер записи в MFT. А запись корневого каталога всегда располагается по одному и тому же адресу!
Рис. 7.8. Восстановленная структура каталогов
Удаленные файловые записи могут ссылаться на уже уничтоженные каталоги. R-Studio собирает их в папку $$$FolderXXX, где XXX – порядковый номер каталога. Поэтому иерархия подкаталогов в большинстве случаев успешно восстанавливается.
Просмотр виртуального дерева обнаруженных файлов осуществляется нажатием кнопки
Рис. 7.9. Красивый интерфейс EasyRecovery еще не говорит о высоком качестве восстановления данных
Нашей целью будет ручное восстановление всего отформатированного раздела без использования дополнительных носителей информации и дорогостоящих утилит от сторонних производителей. Все что для этого потребуется – это любой редактор диска (предпочтительнее всего, конечно же, NT Explorer от Runtime Software, но на крайний случай сойдут и бесплатные Disk Probe и Sector Inspector от Microsoft) в комбинации со встроенной утилитой chkdsk.
В процессе форматирования происходит необратимое разрушение большого количества ключевых структур данных, восстанавливать которые вручную было бы слишком затруднительно. К счастью, для извлечения особо ценных файлов этого и не требуется! Идея состоит в том, чтобы вернуть разделу потерянные файловые записи, а все остальные восстановительные операции поручить утилите chkdsk.
Дизассемблирование показывает, что единственной структурой данных, без которой не может работать chkdsk, является атрибут $DATA файла $MFT. А раз так, все, что требуется сделать, сводится к воссозданию прежнего файла $MFT:$DATA и его размещению поверх старых файловых записей. В простейшем случае, если файл $MFT:$DATA не фрагментирован, это достигается так называемым спекулятивным увеличением его длины. Как это сделать?
Запускаем NT Explorer, переходим в начало MFT (Goto|Mft), выделяем файл $MFT, находим атрибут $DATA (80h) и увеличиваем поля Allocated size, Real Size и Compressed Size на требуемую величину, параллельно с этим корректируя список отрезков (рис. 7.10). Поле Last VCN трогать не нужно, так как оно будет исправлено утилитой chkdsk. Как определить длину нефрагментированного файла MFT? Она равна разнице номеров первого и последнего секторов, в начале которых присутствует сигнатура FILE, умноженной на 512 байт (исключая сектора, принадлежащие $MFTMirr). Известные мне дисковые редакторы не поддерживают поиска последнего вхождения, поэтому соответствующую утилиту приходится писать самостоятельно. К счастью, точную длину MFT определять совершенно необязательно, и вполне допустимо взять ее с запасом, так как лишнее все равно отсеет chkdsk. Действуйте по принципу – лучше перебрать, чем недобрать.
Рис. 7.10. Ручное восстановление MFT. Подчеркнуты поля, подлежащие изменению
Утилита NT Explorer не позволяет редактировать поля в естественном режиме отображения, заставляя нас переключаться в HEX-mode и искать смещения всех значений самостоятельно. Найти заголовок атрибута $DATA очень просто – в его начале расположена последовательность 80 00 00 00 xx 00 00 00 01. В NTFS версии 3.0 она находится по смещению F8h от начала сектора. Поле 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 в кластерах, a YY – стартовый кластер. Стартовый кластер обязательно должен указывать на первый кластер MFT, в противном случае chkdsk не сможет работать. Если новый список отрезков длиннее нынешнего (скорее всего, именно так и будет), то необходимо скорректировать длину атрибутного заголовка (она расположена по смещению 04h от его начала). Проделав эту нехитрую операцию, запустим chkdsk с ключом /F и блаженно откинемся на спинку кресла, созерцая, как возрождаются наши милые папки и файлы. Единственное, что не восстанавливается – так это дескрипторы безопасности. Всем файлам и папкам будут назначены права доступа по умолчанию. Во всех остальных отношениях с отремонтированным таким образом диском вполне можно будет работать, не опасаясь, что он рухнет окончательно. Файлы, ссылающиеся на несуществующие каталоги, складываются в папку Found.xxx. Это – "долгожители", пережившие несколько циклов переформатирования, в буквальном смысле вытащенные из небытия.
Сложнее восстановить том, чья MFT сильно фрагментирована. Прежний список отрезков при форматировании был уничтожен, зеркальная копия также пострадала. Ничего другого не остается, как собирать все фрагменты руками. К счастью, на практике это оказывается не так сложно, как может показаться на первый взгляд. В отличие от всех остальных файлов диска, файл $MFT имеет замечательную сигнатуру file, присутствующую в начале каждой файловой записи. Поэтому все, что нам требуется сделать, сводится к следующим операциям. Последовательно сканируя раздел от первого кластера до последнего, выпишите начало и конец каждого из фрагментов, принадлежащих MFT. Затем из этой цепочки необходимо исключить файл $MFTMirr. Его легко узнать, так как он расположен в середине раздела и содержит копии файловых записей $MFT, $MFTMirr, $LogFile и $Volume, причем $MFTMirr ссылается на себя. В рассматриваемом примере наш список выглядит так: 08h–333h, 669h–966h, 1013–3210h. В грубом приближении ему будет соответствовать следующий список отрезков: 12 2B 03 08 22 23 03 69 96 22 FD 21 13 10 00. Подробная информация о кодировании и декодировании списков отрезков была приведена в гл. 6.
"В грубом приближении" сказано потому, что мы не знаем, в какой последовательности располагались эти отрезки в файле (порядок расположения фрагментов на диске далеко не всегда совпадает с порядком отрезков в списке отрезков). Что произойдет, если порядок сборки файла $MFT окажется нарушен? Внутри MFT все файловые записи ссылаются друг на друга по своим порядковым номерам, представляющим собой индексы массива. Эти ссылки необходимы для восстановления структуры каталогов, организации жестких ссылок (hard links) и еще некоторых служебных структур. Ссылки на родительский каталог дублируются в индексах и восстанавливаются элементарно.
Жесткие ссылки теряются безвозвратно (единственный способ восстановить их заключается в повторении попытки сборки файла $MFT в другом порядке). Однако они практически нигде и никак не используются, так что их потеря не столь уж существенна. По-настоящему туго приходится сильно фрагментированным файлам, занимающим несколько файловых записей, раскиданных по разным фрагментам $MFT. Здесь выручает только перестановка фрагментов. К счастью, количество комбинаций обычно бывает невелико, и процедура восстановления занимает совсем немного времени. Хорошая новость – начиная с NTFS версии 3.1 (соответствующей Windows XP) в MFT номера файловых записей хранятся в явном виде (четырехбайтовое поле, расположенное по смещению 2Ch от начала файловой записи), что делает задачу восстановления тривиальной.
В результате сбоя содержимое дискового тома может стать недоступным операционной системе. При попытке чтения оглавления такого тома будут выдаваться различные сообщения об ошибках (рис. 7.11). Chkdsk сообщает о повреждении MFT и прекращает работу.
Рис. 7.11. Безуспешная попытка прочитать поврежденный том
Не паникуйте! Попробуйте запустить NT Explorer и посмотрите, что он покажет. Маловероятно, чтобы содержимое всего тома было утеряно целиком. Если хотя бы часть файловых записей уцелела, то R-Studio. GetDataBack или EasyRecovery их обязательно восстановят!
Анализ показывает, что основной причиной, по которой chkdsk отказывается проверять том, обычно становится порча файловой записи, описывающей $MFT. Если в процессе обновления $MFT внезапно отключить питание, то такой исход вполне вероятен, особенно на жестких дисках с емким аппаратным кэшем. Такие диски не успевают завершить сохранение секторов, потребляя энергию, накопленную в конденсаторах, а вот их младшие собраться с этим справляются. То же самое происходит при неудачном перемещении файла $MFT или физическом разрушении первого сектора MFT. Зеркальная копия $MFT во всех этих случаях остается цела, однако chkdsk по каким-то таинственным причинам не хочет ей пользоваться, и вы должны восстановить ее самостоятельно. Просто скопируйте первый сектор $MFTMirr в первый сектор $MFT! Поклонники утилиты Sector Inspector могут воспользоваться для этого командным файлом, приведенным в листинге 7.2.
Листинг 7.2. Командный файл для ручного восстановления $MFT из $MFTMirr, XXX – номер сектора $MFTMirr, YYY – номер сектора $MFT
SECINSPECT.EXE -backup d: backup.dsk XXX 1
SECINSPECT.EXE -restore d: backup.dsk YYY CONFIRM
Теперь можно смело запускать chkdsk. Если же chkdsk по-прежнему не работает, это может происходить по одной из следующих причин.
□ Повреждение загрузочного сектора. Решить проблему можно, восстановив загрузочный сектор, используя методику, рассмотренную в гл. 5.
□ Несовпадение списка отрезков файла $MFT:$DATA с истинным началом MFT. Чтобы решить эту проблему, найдите сектор с файловой записью $MFT и исправьте список отрезков. Вопросы, связанные с кодированием и декодированием списка отрезков, были изложены в гл. 6, а методика исправления списка отрезков – ранее в этой главе.
□ Несовпадение размера кластера, указанного в загрузочном секторе с фактическим размером кластера. Определение истинного размера кластера и методика восстановления были рассмотрены ранее в этой главе.
Если же сбой был настолько серьезен, что вместе с $MFT пострадало и зеркало, задача сводится к восстановлению отформатированного диска. При тяжелых разрушениях файловой структуры, когда на диске образуется настоящий кавардак, восстановление тома полезно начинать не с чего-нибудь, а именно с его форматирования. Нет, это не первоапрельская шутка! Утилита format.exe формирует заведомо исправные ключевые структуры, а подключение файловых записей – не проблема. Главное – сохраните список отрезков файла $MFT:$DATA, если, конечно, он еще уцелел. Все остальное – дело техники!
Наш затянувшийся разговор о восстановлении данных подходит к своему логическому завершению, однако NTFS не стоит на месте, а интенсивно развивается. И хотя до сих пор эти изменения носили чисто косметический характер, в Windows Longhorn все обещает кардинальным образом измениться. Microsoft активно работает над новой файловой системой – Windows File System (WinFS). Сроки выхода WinFS постоянно переносятся, что и неудивительно, ведь разработка файловой системы – это не шутка!
По словам вице-президента Microsoft Боба Маглиа (Bob Muglia), WinFS – это все та же NTFS, дополненная расширениями SQL и XML. Насколько изменятся базовые структуры файловой системы, общественности до сих пор неясно. И уж совсем непонятно, зачем NTFS понадобились расширения SQL, когда эти возможности в нее закладывались изначально, просто их не успели завершить. Любой системный программист без проблем напишет драйвер, принимающий SQL/XML запросы и транслирующий их в обращения к драйверу текущей файловой системы! Что-либо менять в самой NTFS совсем необязательно. Как лично мне кажется, это всего лишь очередной маркетинговый трюк, подталкивающий пользователей к переходу на Longhorn!
С другой стороны, развитие NTFS можно только приветствовать, поскольку оно создает широкое поле деятельности всем специалистам по восстановлению данных, ведь старые утилиты с новой файловой системой скорей всего окажутся несовместимы.
При переформатировании диска операционные системы семейства Windows NT никогда не изменяют тип файловой системы, если только им не дать такое указание явно. Поэтому непреднамеренное переформатирование раздела NTFS под FAT16/32 крайне маловероятно. Windows 9x и MS-DOS, напротив, любой диск стремятся отформатировать под FAT16/32, не замечая, что на нем что-то уже находится. Непреднамеренная порча разделов NTFS в процессе установки Windows 9x/MS-DOS поверх Windows NT – обычное дело, через которое проходит уже второе поколение пользователей.
Стратегия восстановления данных во всем похожа на восстановление тома NTFS, случайно переформатированного под NTFS. Единственное отличие состоит в том, что при создании таблицы размещения файлов (file allocation table) первые несколько тысяч файловых записей в MFT затираются безвозвратно. Впрочем, даже их можно попытаться собрать вручную, действуя по методике, описанной ранее в данной главе.
Файлы с уцелевшей файловой записью легко восстанавливаются с помощью утилит R-Studio, GetDataBack или EasyRecovery. Для ручного восстановления всего тома его необходимо заново отформатировать под NTFS, предварительно определив количество секторов в кластере. Далее действуем по плану – увеличиваем размер $MFT, запускаем chkdsk и собираем все, что только можно собрать. Поскольку количество файлов, хранящихся на современных дисках, зачастую исчисляется многими миллионами, потеря первой тысячи из них не так уж и страшна (если только по закону подлости они не окажутся самыми ценными из всего, что хранилось на диске).
Почему погибают дисковые разделы? Ниже приводится список наиболее распространенных причин, отсортированный в порядке убывания их "популярности".
□ Ошибки оператора, вирусы, троянские программы.
□ Отключение питания или зависание системы во время интенсивных дисковых операций, сопровождаемых обновлением MFT (например, удаление/добавление файлов или каталогов).
□ Некорректное поведение различных дисковых утилит (Partition Magic, Ahead Nero, Norton Disk Doctor и т.д.).
□ Физические дефекты оперативной памяти, приводящие к нарушению целостности дискового кэша и, следовательно, к порче самого диска.
□ Некорректное поведение привилегированных драйверов, случайно или преднамеренно "залетающих" внутрь служебных структур драйвера NTFS.
