Для чего применяется журнализация в файловых системах

Реализация файловой системы

Hадежность файловой системы

Жизнь полна неприятных неожиданностей, а разрушение файловой системы зачастую более опасно, чем разрушение компьютера. Поэтому файловые системы должны разрабатываться с учетом подобной возможности. Помимо очевидных решений, например своевременное дублирование информации ( backup ), файловые системы современных ОС содержат специальные средства для поддержки собственной совместимости.

Целостность файловой системы

И если вследствие непредсказуемой остановки системы на диске будут сохранены изменения только для части этих объектов (нарушена атомарность файловой операции), файловая система на диске может быть оставлена в несовместимом состоянии. В результате могут возникнуть нарушения логики работы с данными, например появиться «потерянные» блоки диска, которые не принадлежат ни одному файлу и в то же время помечены как занятые, или, наоборот, блоки, помеченные как свободные, но в то же время занятые (на них есть ссылка в индексном узле ) или другие нарушения.

В современных ОС предусмотрены меры, которые позволяют свести к минимуму ущерб от порчи файловой системы и затем полностью или частично восстановить ее целостность.

Порядок выполнения операций

Рассмотрим пример создания жесткой связи для файла [Робачевский, 1999]. Для этого файловой системе необходимо выполнить следующие операции:

Журнализация

Журнализация реализована в NTFS, Ext3FS, ReiserFS и других системах. Чтобы подчеркнуть сложность задачи, нужно отметить, что существуют не вполне очевидные проблемы, связанные с процедурой отката. Например, отмена одних изменений может затрагивать данные, уже использованные другими файловыми операциями. Это означает, что такие операции также должны быть отменены. Данная проблема получила название каскадного отката транзакций [Брукшир, 2001]

Проверка целостности файловой системы при помощи утилит

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

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

Управление «плохими» блоками

Решение на уровне ОС может быть следующим. Прежде всего, необходимо тщательно сконструировать файл, содержащий дефектные блоки. Тогда они изымаются из списка свободных блоков. Затем нужно каким-то образом скрыть этот файл от прикладных программ.

Источник

Содержание

История

Обоснование

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

Например, удаление файла в файле Unix система включает три шага:

Если сбой происходит после шага 1 и до шага 2, будет потерянный индексный дескриптор и, следовательно, утечка памяти ; если между шагами 2 и 3 происходит сбой, блоки, ранее использовавшиеся файлом, не могут использоваться для новых файлов, что эффективно снижает емкость хранилища файловой системы. Не помогает и перестановка ступеней. Если шаг 3 предшествует шагу 1, сбой между ними может позволить повторно использовать блоки файла для нового файла, что означает, что частично удаленный файл будет содержать часть содержимого другого файла, и изменения любого файла будут отображаться в обоих. С другой стороны, если шаг 2 предшествует шагу 1, сбой между ними приведет к тому, что файл станет недоступным, несмотря на то, что кажется, что он существует.

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

Методы

Некоторые файловые системы позволяют журналу увеличиваться, сжиматься и перераспределяться как обычный файл, в то время как другие помещают журнал в непрерывную область или скрытый файл, что гарантировано не перемещать и не изменять размер во время монтирования файловой системы. Некоторые файловые системы могут также разрешать внешние журналы на отдельном устройстве, таком как твердотельный накопитель или энергонезависимое ОЗУ с резервным питанием от батареи. Изменения в журнале могут сами регистрироваться для дополнительной избыточности, или журнал может быть распределен по нескольким физическим томам для защиты от сбоя устройства.

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

Физические журналы

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

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

Логические журналы

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

Например, добавление к файлу может включать три отдельных записи в:

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

Опасности записи

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

Чтобы усложнить ситуацию, многие запоминающие устройства имеют свои собственные кэши записи, в которых они могут агрессивно переупорядочивать записи для повышения производительности. (Это особенно характерно для магнитных жестких дисков, которые имеют большие задержки поиска, которые можно минимизировать с помощью лифтовой сортировки.) Некоторые журналирующие файловые системы консервативно предполагают, что такое переупорядочение записи происходит всегда, и жертвуют производительностью ради правильности, заставляя устройство сбрасывать свои данные. кэшировать в определенных точках журнала (называемые барьерами в ext3 и ext4 ).

Альтернативы

Программные обновления

В файловых системах с журнальной структурой штраф двойной записи не превышает Это неприменимо, потому что сам журнал является файловой системой: он занимает все устройство хранения и структурирован так, чтобы по нему можно было перемещаться, как в обычной файловой системе.

Файловые системы с копированием при записи

Источник

Надежность дисковой системы NT

Данный материал является продолжением статьи «Файловая система NTFS». В этом обзоре будут подробно рассмотрены вопросы, рассмотрение которых в прошлой статье было поверхностным или отсутствовало вообще. Хотелось бы сразу сказать, что дисковая система NT настолько сложна, что говорить о ней можно еще достаточно долго — и эта статья не опишет всего, что можно было бы рассказать. Так что это лишь попытка координировано и подробно ответить на все вопросы, которые вызвала предыдущая публикация.

Описание того простого факта, что NTFS является журналируемой системой, повергло многочисленных поклонников других файловых и операционных систем в искреннее возмущение. В многочисленных письмах, адресованных мне, NTFS называли системой с квази-журналированием или даже без журналирования вообще, ставя в противовес многочисленные файловые системы Unix. Мне пришло также много писем, указывающих на фатальные сбои NTFS, восстановится от которых не удалось — данные были потеряны. В данной части я попытаюсь, в меру своих сил и понимания, объяснить философию журналирования и средств защиты от сбоев NTFS, а также пояснить причины появления фатальных сбоев. Я постараюсь оправдать подход корпорации Microsoft, которая сделала всё именно так, как сделала — по крайней мере, я изложу причины реализованных технологических решений и те компромиссы, на которые пришлось пойти коллективу разработчиков NTFS.

Журналируемые операции

Прежде всего, хотелось бы рассказать о том, какие именно операции журналируются. Совершенно очевидно, что полный undo-файл, способный откатить абсолютно все операции, абсолютно невозможен как с точки зрения быстродействия, так и с точки зрения здравого смысла. Да, такое журналирование дало бы возможность восстановить большее число данных — например, при осуществлении перезаписи трех мегабайт в середине файла мы могли бы сначала сохранить новые данные в логе, затем переписать туда же предыдущие три мегабайта файла, и уж только затем осуществлять операции с реальными данными. Такой подход гарантировал бы полную определенность с судьбой информации — мы всегда смогли бы понять, какая часть данных уже записалась на диск, а какая находится в исходном, не обновленном состоянии. Он имеет всего один скромный недостаток — небольшая накладочка по быстродействию: для записи на диск трех мегабайт мы вынуждены будем осуществить разнообразные дисковые операции на объем в три раза больший — девять мегабайт. Да, полное журналирование также применяется — но в основном при работе с базами данных. Если вы желаете обеспечить полное журналирование каких-либо данных, вы можете поставить MS SQL или даже Oracle, который вообще не будет пользоваться средствами какой либо файловой системы и обеспечит сохранность ваших данных в любых разумных условиях. Сторонникам же полного журналирования файловой системы я могу ответить одно: решение сократить быстродействие операций записи в три раза, на мой взгляд, является слишком смелым для обязательного применения — и на домашних компьютерах, и на серверах.

Подход разработчиков NTFS был принципиально иным. Главный девиз был, видимо, не «надежность любой ценой», а «неизменность быстродействия». Журналирование просто не должно было помешать работе файловой системы. Первый логичный шаг — отменить полное журналирование как абсолютно неприемлемое с точки зрения быстродействия. В NTFS применяется журналирование логических структур, а не данных пользователя — отсюда и идет фраза, что сохранность данных не гарантируется, но, тем не менее, корректное состояние самой системы будет поддерживаться. То, что NTFS не журналирует данные файлов, приводит на практике к одному варианту потери данных — в том же гипотетическом случае записи трех мегабайт, в случае сбоя в процессе записи никогда уже не удастся установить, какая часть данных записалась, а какая осталась неизменна. Операции, которые, тем не менее, журналируются системой — это операции со структурами самой системы, то есть с файлами и каталогами: добавление файлов, переименование, перенос, создание и удаление (освобождение свободного места). Журналируются также и операции дефрагментации — то есть перемещения фрагментов файлов. Одним словом, все логические операции журналированы.

Отложенная запись и контрольные точки журналирования

Известно, что любая современная система для ускорения файловых операций вынуждена использовать кэширование, в том числе — кэширование операций записи. Так называемая отложенная запись — принцип кэширования, при котором данные, предназначенные для записи на диск, некоторое время сохраняются в кэше и лишь в свободное от других занятий время сохраняются физически. Отложенная запись существенно повышает эффективность дисковых операций, так как такое кэширование группирует множество операций в одну — это особенно эффективно, если запись производится в компактные участки диска. Еще один плюс отложенной записи — не мешать более нужным операциям чтения, и осуществлять запись только тогда, когда система свободна и ей не требуется доступ к диску для других нужд. Как согласовать отложенную запись с журналированием? Это довольно сложный вопрос, так как откладывание записи делает возможным потерю тех данных, которые находились в очереди на физическую запись и не успели записаться на диск до сбоя. Самое неприятное здесь даже не потеря данных, а то, что происходит рассогласование времени записи: какие-то служебные области могут быть обновлены, а какие-то смежные по смыслу — еще нет, так как их обновление могло отложится еще на пару секунд и не состоятся из-за сбоя.

NTFS справляется с этими проблемами с помощью смысловой интеграции операций отложенной записи и ведения журнала. При попытке начать журналируемую операцию в лог тут же записывается намерение — например, стереть файл. Это случается без задержек — на этом этапе отложенная запись не работает: это плата за присутствие журналирования, которой нельзя избежать. Но вот все остальные операции уже идут в задержанном режиме — то есть они могут состояться частично (могут еще в придачу и не в том порядке) или не состоятся вообще. Единственная задержанная операция, работа которой несколько отличается от простой записи — запись в лог об удачном завершении предыдущих транзакций, так называемая контрольная точка. Через определенные промежутки времени — обычно через каждые несколько секунд — система в обязательном порядке сбрасывает абсолютно все задержанные операции на диск. После произведения этой операции в журнал записывается простейшая запись — контрольная точка — которая говорит о том, что все предыдущие операции выполнены корректно на всех уровнях — как на логическом, так и на физическом.

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

Проблемы отложенного журналирования: концепция дублирования информации

Вся вышеописанная теория достаточно хороша, но способна, тем не менее, вызвать очень неприятные последствия, если не учесть еще нескольких вещей, о которых и пойдет речь.

Рассмотрим такой случай: мы стираем файл. Журнал получил запись — «файл N стирается». Затем запаздывающему кэшу стало угодно осуществить сначала физическую пометку о том, что место, занимаемое файлом, освободилось, а уж только затем удалить файл из физических структур MFT и каталога. Допустим, диск находится в активной работе, и на освободившееся место тут же записывается другой файл. В этот момент происходит сбой. Система, загружаясь, исследует журнал и видит незавершенную операцию «файл N стирается» — вернее, как я уже описал выше, не незавершенную, а просто операцию, контрольная точка после которой отсутствует, что автоматически говорит о её незавершенности. Следующая фаза была бы «откат операции» — то есть восстановление файла. Одна незадача — место, физически занимаемое файлом, содержит уже другие данные.

Для недопущения таких ситуаций система, желающая ограничиться логическим журналированием, вынуждена применять принцип «временно занятого места». Место, освобожденное каким-либо объектом или записью о нем, не объявляется свободным до тех пор, пока физически не завершились все операции с логическими структурами. Данный механизм в NTFS, по видимому, не синхронизирован даже с проставлением контрольных точек, так как типичное время освобождения временно занятого места — около 30 секунд, точки же идут чаще.

Данный механизм применяется не только при стирании файла, но и при самых разных операциях: принцип журналирования — объект, убранный или перемещенный на новое место, должен иметь возможность корректно откатить своё «отбытие» — то есть данные, на которые ссылаются логические структуры удаляемого или перемещаемого объекта, необходимо еще на некоторое время зарезервировать как занятое место (диска/каталога). Это еще один шаг NTFS к полному журналированию, где специфическим журналом файловой информации служат сами данные освобождаемых областей, не уничтожаемые физически.

Допущения, обеспечивающие надежность

Четкое выполнение этих требований полностью гарантирует надежную работу NTFS. Структура файловой системы не будет содержать существенных ошибок даже после сбоя. Некоторые несущественные ошибки всё же появляются из-за того, что логика журналирования часто пытается завершить недоделанные операции — например, то же удаление файла — тогда как полную надежность обеспечивал бы только безусловный откат всего, что находится после последней контрольной точки. Малые несоответствия, рождающиеся из этих попыток, относятся к избыточной информации системы безопасности, не представляют никакой реальной опасности для данных — они действительно незначительны. Суть этих несоответствий чаще всего заключается в том, что на диске остаются «лишние» данные о тех режимах доступов, которые уже не понадобятся системе. Их прочистка — дело сугубо повышения производительности, как, например, дефрагментация, поэтому их наличие не является на самом деле ошибкой. В случае же обнаружения серьезных, реальных, проблем драйвер сам установит флажок тома «грязный», что проинструктирует систему проверить том при следующем его монтировании.

Я с большим сожалением должен сказать, что подавляющее большинство фатальных ошибок NTFS происходит по вине аппаратуры, не выполняющей эти элементарные требования. Да, я понимаю, абсолютной надежности не бывает. Но Microsoft пошел по пути разделения труда — за надежность вашей аппаратуры корпорация ответственности не несет. Мой компьютер на 70% не попадает в список совместимого с Windows 2000 оборудования, и то же самое можно сказать про почти любую реальную машину, функционирующую на просторах бывшего СССР. Особенно это относится к любителям разгонять компьютеры. Запомните раз и навсегда: вы с огромной степенью вероятности угробите NTFS в первый же год работы, если ваш процессор — 333, разогнанный на 415. И даже не раз. Мне очень жаль, но это действительно так. От любых сбоев корректного компьютера NTFS защитит, но вот от записи случайных данных в бут-сектор (копия которого, кстати, хранится в самом конце раздела) и в MFT система просто не страхуется. Извините.Часть 5. Программный RAID

Журналирование NTFS, как уже указывалось ранее, ни в коей мере не гарантирует от сбоев с потерей пользовательской информации. Между тем, NT предлагает несколько вариантов создания систем, где, в разумных условиях, гарантируется абсолютно всё. Можно также использовать большее число дисков для обеспечения не повышенной надежности, а, наоборот, повышенной скорости — или того и другого одновременно. О таких конфигурациях и пойдет речь в этой части статьи.

RAID (Redundant Array of Inexpensive Disks) — избыточный массив недорогих дисков. Технология, заключающаяся в одновременном использовании нескольких дисковых устройств для обеспечения характеристик надежности или скорости, отсутствующих у накопителей в отдельности.

Windows NT поддерживает на программном уровне три уровня RAID (так называются стратегии работы дисковых массивов), краткие характеристики которых сведены в следующую таблицу.

Остановимся подробнее на каждом из типов RAID-а.

RAID 0 (параллельные диски)

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

В качестве некоторого вывода — RAID 0 в любом случае существенно повышает быстродействие линейных операций, а с увеличением количества дисков, входящих в набор, существенно повышается скорость работы и со случайными данными. Для эффективной работы с дисковой системой в режиме RAID 0 просто необходим многозадачный режим работы контроллера, а желательно даже разных контроллеров, обеспечивающих доступ к разным дискам. Обязательным условием такой работы на интерфейсах IDE являются Bus-Mastering драйвера. Windows 2000 имеет встроенные драйвера, автоматически включающие этот режим для всех распространенных IDE контроллеров, для NT4 же могут понадобится дополнительные драйвера или изменения ключей реестра.

Надежность RAID 0 низка — отказ каждого диска является фатальным сбоем, точно так же, как и отказ накопителя в случае работы с обычными разделами.

Вероятность сбоя системы в целом только повышается — чем больше дисков вы используете, тем выше вероятность отказа хоть одного из них и, соответственно, потери какой-то части данных тома.

RAID 1 (зеркальные диски)

Самый простой способ обеспечения безопасности данных — создать копию двух дисков. Запись осуществляется на оба диска сразу, что приводит к замедлению этого процесса, тогда как чтение — с того диска, который в данный момент свободен — если, конечно, система способна эффективно осуществить такое чтение (необходимо наличие Bus-Mastering). Реализованный в NT алгоритм, к сожалению, не совсем оптимален и приводит к гораздо более скромному увеличению быстродействия чтения.

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

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

RAID 5 (параллельные диски с четностью)

Данная стратегия представляется в настоящее время наиболее удачной и эффективной схемой работы RAID, состоящих из трех и более дисков. Информация дополняется так называемыми данными четности (parity), которые размещаются на другом физическом диске, нежели реальные данные, контролируемые этой информацией.

Концепцию четности можно понять, например, так: допустим, у нас есть пять бит — например, набор <0, 1, 1, 0, 1>. Мы формируем еще бит — бит четности, шестой, по такому правилу — если число единиц в предыдущих пяти битах четно, он будет равен 1, если нет — 0. В нашем случае число единиц равняется трем, т. е. нечетному числу — наш набор дополнился числом 0 и превратился в <0, 1, 1, 0, 1, >.

Допустим, набору данных причинен урон — <0, X, 1, 0, 1, >. С помощью правила, гласящего нам, что число единиц должно быть нечетно (последний бит), мы можем догадаться, что на месте X стояла единичка. Наш получившийся набор из шести бит (5 бит данных и 1 бит четности) избыточен и может грамотно скорректировать потерю любого из своих шести бит.

Операции четности могут осуществляться не только с битами, но и с любыми объемами данных, что применяется в простейших алгоритмах восстановления данных.

Возвращаемся к устройству RAID 5:

На рисунке изображен массив из пяти дисков. Видно, что каждый диск хранит четыре (условные) части реальных данных и один блок данных четности. Блок четности — скажем, 0 parity — способен восстановить потерю одного из фрагментов — любого, но одного — среди A0, B0, C0 и D0. Все вместе они, в свою очередь, способны восстановить блок 0 parity. Из изображенной структуры RAID видно, что данные, необходимые для полного восстановления всего столбика — то есть информации любого диска в случае сбоя — находятся на других дисках. В этом и заключается восстановление — при записи данных на любой из дисков обновляется также блок четности другого диска, соответствующего текущему блоку (например, при записи в A2 обновляется еще и блок 2 parity). Чтение данных с исправного диска происходит без использования блоков четности, т. е. почти в том же режиме, в каком работает RAID 0. Быстродействие RAID 5 в том виде, в каком это реализовано в NT, даже немного выше, чем у RAID 0.

Единственная накладка — в случае сбоя производительность массива снижается в огромное количество раз, так как при невозможности напрямую считать, например, D4, нужно будет восстанавливать данные этого блока с использованием всех других дисков одновременно — в нашем случае это будут блоки 4 parity, B4, C4 и E4.

Как видно, выход из строя одного из дисков RAID 5 является хоть и не фатальной, но резко аварийной ситуацией — хотя бы из соображений быстродействия чтения с массива. Нетрудно догадаться также, откуда исходит требования как минимум трех дисков — в случае двух накопителей RAID 5 просто вырождается в RAID 1, так как единственный способ создать информацию четности списка из одного элемента — это тем или иным образом дублировать этот элемент.

Допущения, обеспечивающие надежность

RAID предназначен для минимизации ущерба всего в одном случае — при физическом отказе жесткого диска или, возможно, контроллера (в случае многоконтроллерного RAID). Отказы памяти, операционной системы, да и вообще всего остального RAID-ом не предусмотрены — точно так же, как и стратегией работы одиночной NTFS.

И, напоследок, аксиома работы вышеописанных уровней RAID-а — любой сбой одного из дисков системы считается аварией, которую необходимо как можно быстрее ликвидировать. Особенно это относится к RAID 0 и RAID 5, штатная работа которых в условиях аварии одного из дисков практически невозможна.

Более подробно с системой программных RAID Windows NT можно ознакомится в справке к программе (или модулю — в Windows 2000) Disk Administrator, где, собственно, и создаются эти типы дисков. Обращаю ваше внимание, что способности рабочих станций в создании и использовании RAID-ов сильно ограничены — рабочая станция NT4, к примеру, поддерживает только RAID 0 (параллельные диски), тогда как все описанные варианты работают лишь на серверных вариантах операционных систем.Часть 6. Стратегия восстановления томов NTFS

Компьютер с NTFS не загружается. Что делать в этом случае? Как восстановить данные? Возможны два случая, действия в которых несколько отличаются друг от друга. К сожалению, простых стратегий восстановления NT и, соответственно, NTFS не существует — система достаточно сложна и не имеет простейших загрузочных средств, как, например, DOS или Windows95/98.

1. Первый вариант — система находилась на том же NTFS диске. Система просто-напросто перестала загружаться. Что же, тогда нам в 90% случаев предстоит поднимать не NTFS, а просто-напросто саму NT. Данная операция выходит далеко за рамки данной статьи, поэтому описываю лишь способ поставить рядом (на тот же NTFS раздел) еще одну систему NT, на которой можно будет в дальнейшем работать (и которая сможет считать ваши данные).

Пользователи NT4 смогут поставить систему прямо на NTFS, каким-либо образом загрузившись в программу установки.

Вам понадобится CD диск, который представляет собой корректный дистрибутив NT4. Такими свойствами, скорее всего, обладают диски, на которых NT4 находится в каталоге под именем i386, расположенном в корневом каталоге. Команда winnt /?, запущенная в этом каталоге, поможет вам выбрать ключи для создания трех загрузочных дискет, с которых можно будет запустить установку NT4 прямо на диск NTFS. Можно выбрать другой каталог установки — например, winnt2, чтобы затем попытаться реанимировать вашу собственную инсталляцию NT4, если вы видите подходы к этой специфической проблеме, которая под силу только специалистам. Устанавливаемая заново операционная система корректно впишет себя в список загрузи и нисколько не помешает вашему старому NT4.

В случае отсутствия CD в соответствующем формате (симптомы — надпись «вставьте диск с дистрибутивом NT4», не реагирующая на наличие вашего CD) — вам остается только поставить NT на какой-нибудь другой раздел, так как диск с NTFS недоступен из систем, отличных от NT.

Стоит учесть, что NT4 нельзя поставить на NTFS, прошедшую преобразование в новый формат от Windows2000. NT4 всё же читает такой NTFS, но только при наличии пакета обновления SP4 или выше.

Пользователи Windows2000 будут вынуждены найти загрузочный CD диск с Windows2000 (таким является официальный дистрибутив), который сам предложит вам либо поставить систему с нуля, или попытаться восстановить старую инсталляцию. Считать диск NTFS, с которым работал Windows2000, можно только самим Windows2000 или NT4 с пакетом обновления SP4 или выше.

2. Система сама по себе работает, но доступа к диску (не загрузочному, а какому-то другому) нет. Disk Administrator показывает для вашего раздела тип unknown (неизвестный). В подавляющем большинстве случаев это означает, что каким-то образом была осуществлена перезапись загрузочной области (boot sector-а) раздела, и NT действительно не догадывается, что это вообще NTFS. Операционная система NT на всякий случай хранит копию загрузочного сектора в конце раздела — если его скопировать обратно в надлежащее место, в подавляющем большинстве случаев диск опознается как NTFS и починится самостоятельно.

Процесс вычисления правильных адресов достаточно сложен, поэтому я не буду его описывать. Для получения исчерпывающих инструкций для данного случая вам придется пойти на сайт MSDN и найти там статью Knowledge Base под номером Q153973 (скорее всего, вы сможете сделать это простым поиском) — после корректного следования этим инструкциям система по крайней мере опознается как NTFS, и дальнейшая судьба раздела зависит от внутренних средств восстановления NT, которые в таком случае возьмут его в оборот. Вам также поможет скромная на вид команда chkdsk, являющаяся неким ярлычком к системе внутреннего восстановления дисковых систем NT.

Источник