|
Alex Bondarenko
Восстановление тома NTFS
Сбой в системе произошел во время процедуры копировании с одного логического диска на другой (оба логических диска находились на одном физическом диске). Диск (том) которого копировалась информация содержал сбойные кластера. При попытке копирования с этого диска и произошел сбой системы. Windows NT"забыла" записать MFT (Master File Table) для диска на который писалась информация. В результате система перестала воспринимать оба тома как таковые, выводя сообщение о невозможности чтения $Volume.
Схожая ситуация ситуация наблюдается при действии некоторых вирусов, разрушающих boot-сектор или файловую систему. Приминительно к данному случаю я бы отнес произошее к "багу" Windows NT. Мне кажется, что MFT - это последнее, что система может позволить себе "потерять". Тем более, что MFT может находиться практически в любом месте тома, что указывается ссылкой в EBR, и при невозможности записать MFT в сбойный кластер система по идее могла бы записать его в любое другое доступное место. В нашем же случае система потеряла еще и копию MFT. Т.е. баг в чистом виде. Пользователи NT (и соответственно NTFS) - будьте мужественны!
Особой благодарности заслуживает корпорация Microsoft, сделавшая структуру "наиболее защищенной от сбоев" файловой системы (NTFS) очередной "тайной мадридского двора", о которой знают все кроме Knowledge Base. Тем не менее, информацию о структуре BR и EBR корпорация сочла возможным открыть широкой публике
Восстановление MBR и boot-сектора
По мнению автора наиболее "удобоваримой" (вернее было бы сказать традиционной) утилитой для исправления (или создания) MBR является fdisk, входящий в состав любой не слишком “древней” версии Linux.
Но прежде, чем перейти к воссозданию MBR, нам необходимо подробнейшим образом ознакомиться с содержимым диска. Для этого можно установить диск под Linux и воспользоваться программой hexedit с ключем -d. Например, "hexedit -d /dev/hdc". Под NT подойдет hexedit, shareware версию которого можно взять на www.hotfiles.com. Также можно испльзовать diskedit из пакета Norton Utilities.
В Resource Kit, который поставляется с Windows 2000, также есть утилита для работы с диском на низком уровне. К сожелению, автор смог познакомиться с этой утилитой только из замечательно статьи г-на Фролова http://www.certification.ru/library/mp/mp-1099-1.htm. Эту статью настоятельнейшим образом необходимо прочитать, если вы собираетесь "влазить" в NTFS.
Итак в самом начале диска мы видим Master Boot Record. Неважно, что там находится за исключением двух моментов:
Данные о месторасположении томов (Partition Table) на диске начиная со смещения 0x1BE.
Заключительная запись в конце MBR: смещение 0x1FE, байты со значением 0x55, 0xAA.
Структура Partition Table следующая:
|
Byte Offset |
Field Length |
Sample Value |
|
|
0x01BE |
BYTE |
0x80 |
Boot Indicator. Indicates whether the volume is the active partition. Legal values include: |
|
0x01BF |
BYTE |
0x01 |
Starting Head. |
|
0x01C0 |
6 bits |
0x01 * |
Starting Sector. Only bits 0-5 are used. The upper two bits, 6 and 7, are used by the Starting Cylinder field. |
|
0x01C1 |
10 bits |
0x00 * |
Starting Cylinder. Uses 1 byte in addition to the upper 2 bits from the Starting Sector field to make up the cylinder value. The Starting Cylinder is a 10-bit number, with a maximum value of 1023. |
|
0x01C2 |
BYTE |
0x07 |
System ID. Defines the volume type. See Table 1.3 for sample values. |
|
0x01C3 |
BYTE |
0xFE |
Ending Head. |
|
0x01C4 |
6 bits |
0xBF * |
Ending Sector. Only bits 0-5 are used. The upper two bits, 6 and 7, are used by the Ending Cylinder field. |
|
0x01C5 |
10 bits |
0x09 * |
Ending Cylinder. Uses 1 byte in addition to the upper 2 bits from the Ending Sector field to make up the cylinder value. The Ending Cylinder is a 10-bit number, with a maximum value of 1023. |
|
0x01C6 |
DWORD |
0x3F000000 |
Relative Sectors. The offset from the beginning of the disk to the beginning of the volume, counting by sectors. |
|
0x01CA |
DWORD |
0x4BF57F00 |
Total Sectors. The total number of sectors in the volume. |
|
A BYTE is 8 bits, a WORD is 16 bits, a DWORD is 32 bits, and a LONGLONG is 64 bits. Sample values marked with an asterisk (*) do not accurately represent the value of the fields, because the fields are either 6 bits or 10 bits and the data is recorded in bytes. |
Источник: Chapter 1 - Disk Concepts and Troubleshooting
(http://www.microsoft.com/technet/win2000/win2ksrv/reskit/sopch01.asp)
"Продвинутые" системы типа NT и Linux не используют данные о цилиндре, секторе и головке (т.н. CHS). Данные CHS использует только загрузчик системы. Автор статьи надеется, что читателю не придет в голову восстанавливать том файловой системы с целью загрузки с последнего. Поэтому мы воспользуемся данными об относительном адресе начала тома в секторах (0x1C6) и данными о размере тома (0x1CA). Размер сектора составляет в нормальном случае 512 байт (0x200).
Прежде всего необходимо удостовериться в наличии записей Partition Table как таковых. Затем попытаться посмотреть те сектора на диске, на которые указывает запись по адресу 0x1CA. (Для второго основного раздела соответственно 0x1BA и т.д.). Следует также посмотреть на тип файловой системы раздела по адресу 0x1C2. Байт со значением 0x07 означает основной раздел NTFS, 0x05 означает, что запись в PT указывает на Extended Partition Table. Подробнее со значениями этого поля можно ознакомиться на указанной ссылке Microsoft.
Если вы столкнулись с необходимостью восстановления extended partition (т.е. расширенного раздела), то необходимо помнить, что по адресу сектора, указанному в MBR находится сектор содержащий в примитивном виде Boot Sector с Partition Table для extended partition(s). Формат записи Partition Table в данном случае ничем не отличается (смещения те же).
После того, как определено место расположения восстанавливаемого тома, необходимо посмотреть начало этого тома, а именно его Boot Sector и BPB (BIOS Parameter Block).
Boot Record NTFS содержит первые три байта с командой jump, после которой следует OEM ID, а именно "NTFS". Boot Sector NTFS заканчивается так:
…\NTLDR is compressed…………
при этом замыкающие сектор байты имеют значения 0x55 0xAA.
Если Boot Sector в наличии на нужном месте - его необходимо "осмотреть внешне". Если есть подозрения по поводу его целостности, то в NTFS копия Boot Sector'а находится в последнем секторе соответствующего тома, где ее можно взять и записать поверх поврежденной.
Boot Sector Sections on an NTFS Volume
|
Byte Offset |
Field Length |
Field Name |
|
0x00 |
3 bytes |
Jump Instruction |
|
0x03 |
LONGLONG |
OEM ID |
|
0x0B |
25 bytes |
BPB |
|
0x24 |
48 bytes |
Extended BPB |
|
0x54 |
426 bytes |
Bootstrap Code |
|
0x01FE |
WORD |
End of Sector Marker |
BPB and Extended BPB Fields on NTFS Volumes
|
Byte Offset |
Field Length |
Sample Value |
Field Name |
|
0x0B |
WORD |
0x0002 |
Bytes Per Sector |
| 0x0D |
BYTE |
0x08 |
Sectors Per Cluster |
| 0x0E |
WORD |
0x0000 |
Reserved Sectors |
| 0x10 |
3 BYTES |
0x000000 |
always 0 |
| 0x13 |
WORD |
0x0000 |
not used by NTFS |
| 0x15 |
BYTE |
0xF8 |
Media Descriptor |
| 0x16 |
WORD |
0x0000 |
always 0 |
| 0x18 |
WORD |
0x3F00 |
Sectors Per Track |
| 0x1A |
WORD |
0xFF00 |
Number Of Heads |
| 0x1C |
DWORD |
0x3F000000 |
Hidden Sectors |
| 0x20 |
DWORD |
0x00000000 |
not used by NTFS |
| 0x24 |
DWORD |
0x80008000 |
not used by NTFS |
| 0x28 |
LONGLONG |
0x4AF57F0000000000 |
Total Sectors |
| 0x30 |
LONGLONG |
0x0400000000000000 |
Logical Cluster Number for the file $MFT |
| 0x38 |
LONGLONG |
0x54FF070000000000 |
Logical Cluster Number for the file $MFTMirr |
| 0x40 |
DWORD |
0xF6000000 |
Clusters Per File Record Segment |
| 0x44 |
DWORD |
0x01000000 |
Clusters Per Index Block |
|
0x48 |
LONGLONG |
0x14A51B74C91B741C |
Volume Serial Number |
| 0x50 |
DWORD |
0x00000000 |
Checksum |
Источник: Chapter 1 - Disk Concepts and Troubleshooting
(http://www.microsoft.com/technet/win2000/win2ksrv/reskit/sopch01.asp)
Во первых не мешало бы проверить BS включая BPB не предмет соответствия вышеуказанных полей. Указанная в BPB запись со смещением 0x28 указывает размер тома в секторах. Это размер по идее должен совпадать с размером, указанным в Partition Table для соответствующего тома. Значения Bytes per Sector и Sectors per Cluster четко определены для соответствующих размеров томов. Попробуйте найти эту информацию на MSDN.
Осмотрев MBR, Partition Table и Boot Sector восстанавливемого тома можно принять решение о дальнейших необходиых мерах по восстановлению. Т.е. необходимо привести в соответствие данные о размерах томов в MBR с данными в boot секторе тома NTFS. (Или наоборот, смотря что "осталось живым").
После восстановления всех Partition Table автор рекомендует воспользоваться fdisk из Linux для проверки Partition Table. Можно также просто загрузить Linux с установленным сбойным диском и посмотреть, что находится в начале соответствующих разделов, т.е., например:
hexedit -d /dev/hdc1
hexedit -d /dev/hdc5
Если вы при этом увидите Boot Sector'a томов, то можно двигаться дальше.
Запись MFT (Master File Record) является главным файлом (там все является файлом) на томе NTFS.
Процесс восстановления отдельных файлов прекрасно описан г-ном Фроловым http://www.glasnet.ru/~frolov и воплощен в его программе EraseUndo. Поэтому необходимо остановиться на том, что там не описано.
Для успешной работы с MFT целесообразно ознакомиться с документацией на http://www.via.ecp.fr/~regis/ntfs/new/index.html.
FILE record number File name
0 $MFT
1 $MFTMirr
2 $LogFile
3 $Volume
4 $AttrDef
5 . (root directory)
6 $Bitmap
7 $Boot
8 $BadClus
9 $Quota
A $UpCase
B C D E F
10 and higer Any file
Итак, MFT содержит 16 записей файлов, каждая из которых начинается с "FILE" и заканчивается 0xFFFFFFFF. Во-первых, необходимо удостовериться в наличии этих фаловых записей. Чтобы определить, в каком месте находится MFT, необходимо посмотреть в boot sector'е тома номер сектора, в котором находится MFT (смещение 0x30 Boot Sector'a). Не мешает также посмотреть, есть ли в наличии копия MFT (MFT Mirror) в секторе, который указан в BS со смещением 0x38.
В случае нашего сбоя обе таблицы MFT отсутствовали до файла $BadClus !!! К сожалению, ввиду отсутствия информации о содержимом указанных файлов пришлось применить "зверские" меры, а именно скопировать отсутствующие файлы MFT с другого несбойного диска.
ПОСЛЕ ЭТОГО ТОМ ОТКРЫВАЕТСЯ WindowsNT, но файлов там СИСТЕМА НЕ НАХОДИТ.
Наиболее простым вариантом теперь является запуск chkdsk с ключем /f. При этом что-то будет даже найдено, но большинство файлов NT удалит как orphans.
После этого мы имеем:
монтируемый том
кучу удаленных файлов в хорошем состоянии.
НИЧЕГО НЕ ПИСАТЬ НА ДИСК. ВАШИ ДАННЫЕ (ПОЧТИ) ЦЕЛЫЕ. Но при попытке записи система будет естественным образом писать поверх освободившихся индексов.
Дальше автор рекомендует приобрести EraseUndo у господина Фролова или воспользоваться его вышеуказанной статьей для восстановления файлов, либо написать что-то свое.
Все вышеуказанное можно не читать, если воспользоваться утилитой для восстановления файлов под NTFS Tiramisu http://www.recovery.de). Теперь эта утилита называется Easy Recovery. Существуют также версии этой утилиты для восстановления файлов в системах FAT. Есть несколько недостатков в использовании этой утилиты: во-первых вы потеряете все длинные имена файлов (существует только DOS-версия этой утилиты), а во-вторых — нельзя копировать восстановленные файлы на диски NTFS(это можно сделать только в том случае, если у вы установите на диск драйвер, позволяющий видеть диск NTFS) и в-третьих - Tiramisu довольно дорогое удовольствие.
УДАЧИ ВСЕМ !
Todo List для разработчиков Windows NT (2000).
Сделать еще одну копию MFT (если двух мало), которая бы периодически обновлялась, но не затрагивалась бы при каждом изменении файловой системы.
Убрать саму возможность исчезновения обеих таблиц MFT.
Добавить в chkdsk возможность восстановления записей MFT при ее отсутствии из других доступных данных (об индексах и т.п.)
© Alex Bondarenko