ПO резервирования глазами администратора

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

В предыдущем номере LAN мы рассматривали аппаратные средства резервного копирования и архивирования. Теперь настала очередь поговорить о программных средствах.

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

Программы резервного копирования можно условно разделить на три категории.

1. Системы начального уровня. К ним, в первую очередь, следует отнести программы, поставляемые в комплекте с сетевыми операционными системами. Это SBACKUP в Novell NetWare и Ntbackup (облегченная программа Seagate Backup Exec) в Windows NT Server. ОС UNIX содержит множество утилит для резервного копирования: backup, dump, rdump, cpio, dd, tar, pax, restore, rrestore (набор утилит варьируется от одной версии UNIX к другой). Некоторые реализации UNIX включают облегченные версии более мощных систем резервного копирования, в частности в SCO OpenServer входит ARCserve Lite компании Computer Associates. Системы начального уровня не могут похвастаться богатством функциональных возможностей, а в большинстве своем - и удобством пользовательского интерфейса.
2. Системы среднего уровня. К ним относится большинство программ резервного копирования, продаваемых на рынке. Наиболее яркими представителями являются ARCserve компании Computer Associates (подразделение Cheyenne), Backup Exec компании Seagate Software и NetWorker компании Legato Systems. Эти продукты рассчитаны на работу в наиболее популярных сетевых ОС NetWare и Windows NT, а часть из них может функционировать в среде UNIX и OS/2. Агенты резервного копирования этих систем поддерживают практически все более-менее известные операционные системы и базы данных. Программы среднего уровня обладают широкими функциональными возможностями и удобным пользовательским интерфейсом. Цены на них зависят от числа пользователей, от количества серверов в сети, от поддержки агентов резервного копирования и от ряда других параметров. Обычно заказчику они обходятся в сумму от 500 до 2000 долларов в пересчете на один сервер.
3. Программы для корпоративных гетерогенных систем. Они обладают очень мощными средствами резервного копирования и архивирования данных в сложной распределенной сетевой среде. К их числу можно отнести продукт ADSM (ADSTAR Distributed Storage Manager) компании IBM. Системы уровня ADSM поддерживают практически любые ОС, включая MVS и AS/400, а также множество СУБД. Для заказчика такая система будет стоить от 5000 долларов в самой простой конфигурации до многих десятков тысяч - в сложных.

ПРОГРАММНЫЕ КОМПОНЕНТЫ СИСТЕМ РЕЗЕРВНОГО КОПИРОВАНИЯ

Большинство систем резервного копирования в качестве внешних носителей поддерживают только накопители на магнитных лентах (устройства с последовательным доступом). Кроме простых программ в UNIX, наподобие dump, cpio, tar, все остальные работают в архитектуре клиент-сервер и состоят из трех типов компонентов: сервер системы, консоль управления и агенты резервного копирования. Рассмотрим эти компоненты более подробно на примере популярной коммерческой программы резервного копирования ARCserve for NetWare (см. Рисунок 1).

Серверный компонент системы ARCserve устанавливается на один из серверов NetWare с подключенным к нему накопителем на магнитной ленте. Этот компонент отвечает за обработку трафика резервного копирования, ведет журналы операций и отвечает за обращение к накопителю на магнитных лентах. (Кроме ARCserve for NetWare Cheyenne предлагает ARCserve for Windows NT и ARCserve/Open for UNIX, где в качестве серверной платформы выступают Win-

dows NT или UNIX соответственно. Другие системы среднего или высшего уровня также обычно поддерживают эти платформы.) Управление системой осуществляется с консоли ARCserve, устанавливаемой на одну из клиентских машин с ОС Windows. В некоторых случаях (например, ARCserve for NT) консоль и сервер могут располагаться на одной машине. На компьютере, данные с которого будут подлежать резервному копированию, размещают программный агент ARCserve. Разумеется, в первую очередь агент устанавливается на сервере ARCserve, хотя это и необязательно. Агенты существуют для множества операционных систем, а также для систем управления базами данных. Именно агенты отвечают за взаимодействие с сервером ARCserve, обеспечивая пересылку данных.

ТРЕБОВАНИЯ К СИСТЕМАМ РЕЗЕРВНОГО КОПИРОВАНИЯ

Чтобы не повторять прописные истины, мы не станем подробно разбирать само собой разумеющиеся требования, такие как поддержка всех основных сетевых и клиентских ОС или ведение подробных журналов выполняемых операций и сообщений. Несмотря на самоочевидность такого требования, как надежность работы самой программы резервного копирования, здесь, к сожалению, не все так просто. Если в среде Windows NT и UNIX дела обстоят более или менее гладко, то NetWare может серьезно затруднить выполняемую задачу. Существует аксиома, что чем больше на ком-

пьютере выполняется программ, тем он менее устойчив в работе. Это особенно наглядно проявляется в случае NetWare. Следует помнить, что отладка надежной работы программы в NetWare занимает гораздо больше времени, чем в случае Windows NT или UNIX. Так, программа ARCserve сама по себе достаточно устойчива. Но если на сервере кроме нее работают другие приложения (система сетевого управления, антивирусная программа, система электронной почты и т. п.), то администратору придется немного попотеть над тем, чтобы сервер нормально функционировал и не падал в самое неподходящее время.

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

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

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

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

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

Разные системы задействуют различные критерии для определения модификации файла со времени последнего резервного копирования. Самым распространенным способом в среде DOS, Windows и NetWare является использование атрибута Archive. При создании или модифицировании файла данный атрибут автоматически выставляется прикладными программами. При резервном копировании этот атрибут убирается. Поэтому, в теории, система резервного копирования может таким образом определить, что файл еще не копировался на ленту. К сожалению, в жизни не все так просто. Ряд прикладных программ принудительно убирают этот атрибут при работе с файлами. Таким образом, система резервного копирования будет считать, что у файла есть копия на ленте, хотя это и не так. Это ведет к опасности того, что файлы окажутся вообще без резервных копий. Кроме того, здесь возможна и иная неприятная ситуация. Если файл восстановлен с резервной копии, то он получает атрибут Archive, хотя его копия на ленте уже существует. Вдобавок, ряд прикладных программ при обращении к файлам выставляют этот атрибут, даже если файл не модифицировался.

И при инкрементальном или дифференциальном резервном копировании файлы копируются повторно, в результате длительность процедуры копирования возрастает.

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

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

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

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

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

Чтобы система резервного копирования могла работать длительное время в автоматическом режиме (в пределах недельного или месячного цикла), она должна поддерживать автозагрузчики и библиотеки. Неплохо, если система может работать с массивами RAID на магнитных лентах, а также если в ее состав входят антивирусные средства. Важна и встроенная поддержка типовых схем ротации картриджей магнитных лент (циклической, "дед-отец-сын" (GFS), "Ханойская башня", "10 наборов" и т. п.). Хорошая система должна сама маркировать картриджи, поддерживать штрих-коды, назначать уникальные идентификаторы лент для разных процедур копирования. Желательно, чтобы процедуры резервного копирования/восстановления данных можно было инициализировать как с агента резервного копирования, так и с сервера. Только система, удовлетворяющая подобному перечню требований, может считаться подходящей для сетевой среды.

ТРЕБОВАНИЯ К ВОССТАНОВЛЕНИЮ ДАННЫХ

При восстановлении каталогов с резервной копии хорошая система резервного копирования должна предоставлять возможность выбора: либо восстанавливать каталоги точно в том виде, какими они были на момент резервного копирования; либо восстанавливать только отсутствующие файлы; либо переписывать имеющиеся файлы или переписывать файлы, время создания/обновления которых более позднее, чем у имеющихся на жестком диске. Желательно, чтобы процессом восстановления файлов можно было управлять интерактивно. Однако не всегда системы начального и среднего уровня могут в полной мере обеспечить все эти возможности. Особенно плохо они справляются с задачей восстановления каталогов и файловых систем в том состоянии, которое они имели на момент резервного копирования. Это может привести к очень неприятным последствиям. Вот пример из жизни.

В одной организации меня попросили установить SCO OpenServer в качестве сервера Internet (в этой компании до этого времени UNIX не использовали). После настройки система работала нормально и устойчиво, а ее содержимое было скопировано с помощью ARCserve Lite. Через некоторое время меня попросили поменять некоторые настройки (в частности, IP-адреса и маршруты), что и было сделано. Затем по ряду причин все изменения потребовалось сбросить в исходное состояние. Ничтоже сумняшеся, я предложил все данные восстановить с резервной копии. Почти сразу администратор организации стал жаловаться, что сервер не работает. И что же выяснилось? В ОС UNIX имеется каталог /etc, где хранятся многие системные файлы. Ряд демонов (фоновых процессов в UNIX) запускается автоматически, если в этом каталоге присутствуют соответствующие конфигурационные файлы. В частности, при наличии файла /etc/gated.conf запускался демон маршрутизации gated, а при отсутствии файла - демон routed. При инсталляции ОС сервер был настроен на службу routed. При переконфигурации были изменены IP-адреса и задействован более мощный сервис gated со своими настройками, не совместимыми с предыдущим сервисом. Когда данные восстанавливались с ленты, система резервного копирования сохранила все вновь созданные файлы, включая /etc/gated.conf. IP-адреса пришли в несоответствие с маршрутами, и это привело к конфликту. Система резервного копирования оказалась неспособна полностью вернуть каталоги в исходное состояние. Аналогичные ситуации характерны и для других ОС. Например, NetWare по-разному работает в сети TCP/IP, в зависимости от того, существует ли файл SYS:ETCRESOLVE.CFG (он создается администратором вручную лишь после инсталляции ОС). Такое же явление можно наблюдать и при работе с прикладными программами. Конечно, данные можно восстановить в другой каталог и затем сравнить их с имеющимися. Но если каталогов несколько десятков? Или если мало места на диске?

Но это еще цветочки. Некоторые системы начального уровня (в частности, SBACKUP) восстанавливают стертые файлы. Поясню феномен на примере. Допустим, на томе VOL1 сервера NetWare имелись каталоги DIR1 и DIR2. После полного резервного копирования их содержимое было перенесено на ленту. Далее нужда в этих каталогах исчезла, и они были удалены (заметьте, специально, а не случайно). Обновленную информацию с помощью инкрементального (или дифференциального) копирования поместили на ленту. Но после восстановления с полной резервной и далее инкрементальной копии они вновь появятся на диске. К каким последствиям это может привести? Во-первых, диски оказываются засоренными ненужными файлами, с которыми администратору придется разбираться отдельно. Во-вторых, места для восстановления данных может просто не хватить. И чем реже проводится полное резервное копирование, тем хуже. Если в такой ситуации восстанавливается том SYS, то это запросто может привести к краху всей системы. В-третьих, здесь может наблюдаться то же явление, что и в вышеприведенном примере с UNIX: восстановленные файлы могут сбить настройку системы.

ТРЕБОВАНИЯ К АРХИВИРОВАНИЮ

Во многом требования к архивированию/разархивированию идентичны требованиям к резервному копированию. Правда, методы инкрементального и дифференциального копирования подходят для архивирования не лучшим образом. Для архивов характерны очень большой объем хранимой информации и, соответственно, размер журналов выполняемых операций. Система архивирования должна обеспечивать быстрый и удобный поиск файлов по версиям и времени создания, а также поддерживать автоматическое удаление файлов по прошествии заданного времени. Здесь поддержка библиотек еще более важна, чем в случае резервного копирования. Такие типовые схемы, как "дед-отец-сын" и "Ханойская башня", не подходят для архивирования. Лучшим выбором будет циклическая схема ротации всех картриджей в пределах срока архивации.

Проблемы при разархивации здесь те же, что и при восстановлении данных. Например, редко какая система может вернуть из архива каталог точно в то состояние, в каком он находился на момент архивирования.

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

НА ЧТО ОРИЕНТИРОВАТЬСЯ СИСТЕМНОМУ АДМИНИСТРАТОРУ

Если руководителей российских организаций трудно, но все же можно уговорить приобрести аппаратные средства резервного копирования, то заставить купить программные средства - практически невозможно. Логика начальства железная. Если в состав сетевой операционной системы уже входит программа резервного копирования, зачем тратить деньги на что-то другое? Только работать с такой программой предстоит не начальству, а системным администраторам. И, кроме нервотрепки, эти примитивные программы ничего не дадут.

Пожалуй, самой бедной программой по части функциональных возможностей является SBACKUP, поставляемая в составе NetWare. Сама операционная система NetWare далеко не блещет средствами по автоматизированному управлению сервером. Написать для нее программу, работающую по расписанию, может только системный программист. Хорошо еще, что начиная с NetWare 4.11 в систему входит интерпретатор Basic (NetBasic). Но что делать с более ранними версиями NetWare? А тут еще SBACKUP не содержит даже самых минимальных средств написания сценариев. Каждый раз опции резервного копирования приходится задавать вручную. Разумеется, ни о какой поддержке автозагрузчиков или сложных фильтров здесь речь не идет. Хотя SBACKUP поддерживает все три метода резервного копирования, она может оперировать только атрибутом Archive. Консоль управления и сервер копирования размещаются на одной и той же машине - сервере NetWare. Интерфейс программы - текстовый и не очень удобный. Начинающие администраторы сталкиваются с немалыми трудностями при работе с SBACKUP. (Например, очень часто можно услышать вопрос, почему в NetWare 4.x, набрав имя .Admin.Organization и пароль, администратор получает сообщение, что такого пользователя нет? Необходимо вводить полное квалифицированное имя пользователя .CN=Admin.O=Organization.) Как уже было сказано ранее, программа очень плохо справляется с восстановлением данных. Уровень услуг и качество здесь крайне низки.

Ntbackup в составе Windows NT на этом фоне выглядит более привлекательно, хотя и она не блещет. Программа не имеет таких откровенных ляпов, как в SBACKUP, но и ей очень далеко до полной версии Seagate Backup Exec for Windows NT.

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

Для решения задач архивирования программы начального уровня не пригодны даже в самых простых случаях.

Ситуация с UNIX несколько иная. Хотя программы backup, dump, rdump, cpio, dd, tar, pax, restore, rrestore также не впечатляют своими характеристиками, возможности самой операционной системы настолько богаты, что нетрудно написать сценарии с самыми немыслимыми (для других систем) возможностями. В частности, несмотря на хорошо развитые средства фильтрации в Seagate Backup Exec или Cheyenne ARCserve, с помощью конвейеров UNIX и утилит наподобие awk, администратор может самостоятельно создать поистине бесподобные и уникальные фильтры, а в качестве критериев модификации файлов при инкрементальном и дифференциальном копировании он может задействовать безошибочные механизмы контроля циклической четности содержимого файлов.

Немногие опытные системные администраторы UNIX используют коммерческие программы резервного копирования. И их можно понять. Но все-таки для сложной распределенной сетевой среды, куда помимо UNIX входят и другие платформы, альтернативу программам класса NetWorker for UNIX компании Legato Systems найти трудно.

Производители самых распространенных систем среднего уровня выпускают продукты сразу для всех популярных сетевых платформ: NetWare, Windows NT и UNIX (только компания Seagate Software не имеет программы для UNIX). Системы имеют примерно одинаковые возможности. Говорить о преимуществах той или иной программы - значит выставлять напоказ собственные вкусы и пристрастия. Продукты удовлетворяют практически всем требованиям, предъявляемым к системам резервного копирования и восстановления данных, в частности поддерживают автозагрузчики, RAID-накопители, копирование по запросу агента и сервера, большое разнообразие баз данных, основные клиентские ОС. Кроме того, для управления они позволяют привлекать различные сетевые средства, в том числе электронную почту, протокол SNMP и выдачу сообщения на пейджер. Системы обладают достаточно удобным графическим пользовательским интерфейсом, хотя и несколько громоздким для большинства решаемых задач. Некоторые версии имеют средства интеграции с системами иерархического хранения HSM, что особенно важно для больших хранилищ данных. Но все же с точки зрения архивирования эти системы значительно уступают возможностям ADSM компании IBM.

Среди программ наблюдается своеобразное распределение территории влияния. Для сетей NetWare самой популярной является Cheyenne ARCserve for NetWare, для Windows NT - Seagate Backup Exec, а для UNIX - Legato NetWorker. Но это в цивилизованном мире. В России ситуация несколько иная. Здесь в NetWare и Windows NT доминирует ARCserve. Прежде всего, это объясняется активной маркетинговой политикой основных партнеров Computer Associates (в состав которой входит Cheyenne) в России, и в первую очередь компаний "Интерпоком ЛАН" и Ланит. Помимо этого, немалую роль играет более чем благосклонное отношение к этому продукту со стороны Novell, которая включила в ряд своих сетевых продуктов утилиты Cheyenne. Во многих организациях, где осуществляется переход с NetWare на Windows NT, ARCserve остается основной корпоративной системой резервного копирования. Администраторам редко когда придет в голову менять привычный, хорошо зарекомендовавший себя продукт на что-то новое. Как говорится, от добра добра не ищут. Кроме того, ARCserve for Windows NT имеет ряд функций, отсутствующих в аналогичном продукте для NetWare. Особый интерес среди них представляет возможность посекторного копирования диска. Но в семье не без урода. ARCserve для UNIX откровенно слаба и по своим возможностям значительно проигрывает тому же NetWorker.

Продукты Seagate Software пока мало известны у нас в стране, хотя ситуация меняется. Так, Windows NT Server содержит облегченную версию Backup Exec, поэтому администраторам Windows NT будет нетрудно освоить полную версию пакета. Это особенно привлекательно для организаций, где никогда прежде не было серьезных систем резервного копирования. Боюсь, что перспективы Backup Exec для ОС NetWare значительно более туманны - здесь слишком сильны позиции ARCserve. Поставками Seagate Backup Exec у нас занимаются несколько компаний, среди которых можно выделить "Стинс Коман" и Arbyte Computers.

Очень неплохая продукция компании Legato Systems у нас известна еще меньше. Наверное, это связано с тем, что наиболее мощная ее версия реализована для UNIX. Но крупных сетей UNIX в России относительно немного, а администраторы мелких сетей предпочитают использовать утилиты, поставляемые с ОС. Тем не менее версии NetWorker для NetWare и NT вполне конкурентоспособны, хотя и несколько дороги. Дистрибьютором продуктов Legato Systems в России выступает системный интегратор "АйТи".

Помимо перечисленных в России можно встретить и ряд других программ, в частности производства компаний Symantec и Palindrome.

По сравнению с системами среднего уровня, продукт ADSM компании IBM имеет почти беспрецедентные возможности. Версии ADSM имеются для ОС MVS, AS/400, AIX, HP-UX, Solaris, OS/2, Windows NT. Бросается в глаза отсутствие серверной реализации для NetWare. IBM объясняет это невысокой надежностью NetWare для предоставления такого сервиса. Агенты резервного копирования ADSM имеются практически для всех существующих платформ, включая такие экзотические, как Cray Unicos или NEC EWS. Система ADSM обладает уникальной функцией по типу иерархического хранения HSM. Например, резервное копирование в сети может производиться на массив дисков RAID, а затем на магнитооптику и библиотеку магнитных лент. За счет этого производительность резервного копирования и архивирования резко возрастает.

Функции резервного копирования и архивирования отделены друг от друга и выполняются программно различным образом. В области архивирования система не имеет конкурентов. В отличие от других систем, ADSM поддерживает прозрачное уплотнение магнитных лент после удаления ненужной информации. Для работы система ADSM задействует так называемые push-агенты (некоторые реализации систем среднего класса также их поддерживают). Push-агенты позволяют фильтровать и упаковывать архивируемую информацию на стороне клиента, тем самым резко повышая производительность работы. Для резервного копирования в ADSM применяются только два метода: полное и инкрементальное копирование. Зато при инкрементальном копировании задействуется достаточно мощный критерий выбора: дата создания и модификации вместе с размером и атрибутами файлов (кроме атрибута Archive). IBM считает, что использование в качестве критерия атрибута Archive нерационально.

Но даже у этой мощной системы есть недостатки. Во-первых, не может не огорчать пристрастие IBM к командной строке. Пользовательский интерфейс системы - один из самых бедных. Файлы конфигурации приходится редактировать вручную. Во-вторых, продукт достаточно дорого стоит. Не каждому он по карману. Еще одним недостатком может считаться отсутствие поддержки протокола SNMP. Это удивительно для продукта, предназначенного для крупных сетей. Однако ADSM хорошо интегрируется с платформой управления сетью Tivoli Management Environment компании IBM.

ЗАКЛЮЧЕНИЕ

Даже учитывая российские реалии, я бы не стал рекомендовать администраторам использовать программы резервирования, поставляемые с сетевой ОС (за исключением UNIX). Слишком они слабы.

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

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

Системы верхнего уровня несколько громоздки и чрезвычайно дороги. Но это лучший выбор для централизованного резервирования и архивирования в крупных и сложных гетерогенных сетях.

МЕТОДЫ РЕЗЕРВНОГО КОПИРОВАНИЯ

Три метода резервного копирования

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

Основные методы резервного копирования следующие: полное, инкрементальное (incremental) и дифференциальное (differential).

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

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

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

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

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

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