Резервное копирование как средство выживания

Возможности программного обеспечения резервного копирования и архивирования.

Храните деньги в сберегательной кассе!

Из лозунгов

Резервное копирование — это, так сказать, серые будни администратора.

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

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

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

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

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

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

1. Резервное копирование (backup). Как следует из названия, резервное копирование предназначено для хранения информации на внешних носителях с тем, чтобы ее можно было восстановить при авариях или сбоях в информационных системах. Например, в случае выходя из строя винчестера операционную систему можно восстановить с резервной копии. В англоязычной литературе процедура восстановления обозначается как restore или recovery.

2. Архивирование (archive). Архивирование призвано обеспечить долгосрочное сохранение наработанной информации. Часто такая информация уже не требуется для текущей работы, но тем не менее может понадобиться для получения справки, для сверки, проверки или в качестве исходной для какой-то будущей разработки. Например, архивированию подлежит бухгалтерская документация или законченные проекты. Процедура восстановления данных из архива называется разархивированием, или извлечением (retrieve).

3. Системы иерархического хранения данных (Hierarchical Storage Management, HSM). Внешние накопители могут быть использованы для оперативного и интерактивного хранения информации, аналогично тому, как используются винчестеры. В системах HSM медленные, но емкие внешние накопители могут выступать в качестве второго (магнитооптика) или третьего (магнитные ленты) уровня хранения. Файлы, к которым пользователи давно не обращались, переносятся (мигрируют) с винчестеров на накопители второго или третьего уровня. При обращении файл снова автоматически перемещается на винчестер.

Ввиду специфики систем HSM, в данном обзоре они рассматриваться не будут; читатели могут подробно ознакомиться с характеристиками HSM в статье «Иерархическое хранение данных» в апрельском номере LAN за 1999 год.

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

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

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

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

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

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

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

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

Главной проблемой инкрементального и дифференциального копирования является проблема выбора надежного критерия для установления факта модификации файла. Обычно в качестве такового выступает атрибут Archive (для систем DOS/Windows), время создания/модификации файлов, размер файла или контрольная сумма содержимого файла. К сожалению, все они имеют те или иные недостатки, связанные с особенностями обработки атрибутов и прав доступа отдельными прикладными программами.

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

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

2. В настоящее время на рынке доминируют системы среднего уровня, поскольку при относительно невысокой цене они обладают широкими возможностями по резервному копированию и архивированию. Подобных систем множество, наибольшей же известностью среди них пользуются ARCserveIT компании Computer Associates, Backup Exec от Seagate Software и NetWorker компании Legato Systems.

3. Системы старшего уровня предназначены для резервного копирования и архивирования в сложных гетерогенных средах. При этом они поддерживают самые разнообразные аппаратные платформы, операционные системы, базы данных и приложения корпоративного уровня. Они имеют прекрасные средства интеграции с системами управления сетью и обеспечивают самые разнообразные аппаратные конфигурации резервного копирования/архивирования. К подобным системам можно отнести ADSM компании IBM и OpenView OmniBack II от Hewlett-Packard. К сожалению, для многих организаций они слишком избыточны и весьма дороги.

За исключением программ начального уровня, все системы резервного копирования/архивирования реализованы в архитектуре клиент-сервер (см. Рисунок 1). Серверный компонент системы резервного копирования/архивирования устанавливается на один из серверов (это может быть NetWare, Windows NT, UNIX, MVS и т. д.). К этому же серверу подключаются внешние накопители, например стримеры или библиотеки магнитных лент. Именно сервер системы резервирования выполняет реальную работу по резервному копированию и архивированию на ленты.

Рисунок 1. Архитектура системы резервного копирования/архивирования.

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

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

Что лучше? К сожалению, однозначного ответа на этот вопрос нет, все зависит от конкретной ситуации. Плюсом централизованного размещения является то, что оно позволяет значительно снизить затраты на установку и эксплуатацию системы резервного копирования и архивирования. Однако централизованный вариант годится только для случаев, когда все объекты резервного копирования соединены высокопроизводительной сетью. Если счет подлежащих резервированию серверов и рабочих станций идет на десятки и сотни, то это неблагоприятно сказывается на времени, необходимом для резервирования. В этом случае рекомендуется использование сетей устройств хранения (Storage Area Network, SAN), тем более что современные программные и аппаратные средства резервного копирования поддерживают эту технологию.

Децентрализованное размещение — единственно возможный вариант при наличии филиалов, подключенных по медленным каналам связи.

Рассуждать о том, какая конкретная система резервного копирования лучше, а какая хуже — дело бесперспективное, особенно если речь идет о системах среднего и старшего уровня. Многое зависит от того, какие операционные системы, СУБД, распределенные приложения работают в сети, наконец, какую топологию имеет сеть. Поэтому мы не будем останавливаться на возможностях отдельных систем, во всяком случае, отвлеченно от решаемых задач. Каждая из систем имеет свои изюминки и, к сожалению, недостатки. Задача администратора состоит в том, чтобы из всего разнообразия продуктов выбрать тот, который оптимально подходит для его сети. А для этого он должен сформулировать для себя конкретные цели, которых он хочет добиться. Мы же поговорим об общих требованиях, предъявляемых к программным средствам резервного копирования и архивирования.

РЕЗЕРВНОЕ КОПИРОВАНИЕ

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

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

2. Ошибки и сбои в операционных системах и прикладном программном обеспечении. В любом ПО всегда имеются ошибки, при определенных условиях они могут привести к порче данных.

3. Вирусы и «троянские кони». Очень распространенная причина потери информации, особенно в системах Windows. Однако и в других ОС разного рода закладки и «троянские кони» не раз приводили к таким серьезным последствиям, как утрата или несанкционированное изменение информации.

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

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

Использование системы резервного копирования на внешние носители вовсе не обязательно может быть вызвано всеми перечисленными причинами, с некоторыми из них можно бороться другими способами. Уменьшить риск потери информации в результате поломок оборудования и в некоторых случаях сбоев ПО позволяет применение таких отказоустойчивых конфигураций, как массивы RAID и кластеры. Однако от таких опасностей, как вирусы, ошибки пользователей или атаки хакеров, отказоустойчивые решения не спасают. А ведь, как говорилось выше, именно непреднамеренное уничтожение данных является самой распространенной причиной потери информации. Далеко не всегда оно заканчивается потерей всего одного-двух пользовательских файлов, хотя и это тоже неприятно. В нашем издательстве за последний год два раза имели место такие случаи, когда, находясь в корневом каталоге (/), системный администратор UNIX по небрежности выполнял команду:

rm   -r   *

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

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

ВОССТАНОВЛЕНИЕ ОС

Особо тяжелый случай представляет восстановление операционной системы целиком, поэтому мы остановимся на нем подробнее. Помимо обычных файлов каждая ОС содержит системную информацию, причем иногда она хранится в специализированных базах данных. Например, в NetWare 4.x и 5.x используется служба каталогов NDS, причем эта служба недоступна через обычные файловые операции (она хранится в скрытом каталоге SYS:_NETWARE, в нем же содержатся и другие системные данные). В Windows NT системная информация размещается в реестре, а также в некоторых файлах, в частности, WINS.MDB, SYSTEM.MDB и т. д. В UNIX часть системной информации содержится в обычных текстовых файлах наподобие /etc/passwd, /etc/inetd.conf, тогда как остальная может храниться в специализированных БД (например, информация по сетевой информационной службе NIS/NIS+).

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

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

Затем администратору приходится вручную переустанавливать операционную систему сервера и инициализировать ее так же, как в исходном варианте. Например, для корректного восстановления сервера NetWare необходимо с самого начала присвоить ему исходное имя сервера, создать дерево NDS с прежним именем и поместить сервер в тот же контейнер NDS, задать старые сетевые адреса и некоторые другие параметры. Таким образом, администратор должен заранее позаботиться о том, чтобы где-то зафиксировать эту информацию. В противном случае, толку от резервной копии ОС будет немного. Только после выполнения всех указанных действий администратор может, наконец, приступить к восстановлению информации с резервной копии.

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

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

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

Много подводных камней возникает при восстановлении сервера NetWare 4.x и 5.x, особенно если в сети он один, что связано с трудностями «реанимации» службы каталогов NDS. Определенную помощь здесь может оказать статья «Восстановление данных при аварии NetWare 4.x» в майском номере LAN за 1998 г., где описан порядок действий администратора в такой ситуации.

Некоторые коммерческие системы резервного копирования имеют средства для облегчения восстановления сервера. Например, входящий в комплект ARCserveIT модуль Disaster Preparation and Recovery позволяет вернуть сервер резервирования к жизни в полуавтоматическом режиме. Правда, разбивать диски на файловые системы и заново инсталлировать ОС все равно приходится вручную. В коммерческих системах имеются и более мощные средства восстановления после аварии, но они продаются отдельно. В частности, для уже упоминавшегося ARCserveIT поставляется дополнительный модуль Disaster Recovery Option для автоматического восстановления сервера. Модуль сам разбивает диски на файловые системы (как это было на момент аварии) и инициализирует начальный образ ОС, после чего ARCserveIT полностью восстанавливает с магнитной ленты ОС, все системное и прикладное программное обеспечение. К сожалению, по непонятным причинам, конечные потребители такие модули заказывают нечасто, хотя по цене они вполне доступны.

Мощные UNIX на платформе RISC имеют в своем составе средства резервного копирования (для пользователя они бесплатны), применение которых позволяет кардинально упростить процедуру восстановления компьютера. Например, в AIX (UNIX от IBM) входит утилита sysback. Эта утилита позволяет создать на магнитной ленте загрузочный образ ОС, а также скопировать туда прикладное ПО. Кроме того, sysback заносит всю информацию по томам системы, их расположению и т. д. Компьютер достаточно загрузить с магнитной ленты (во многих RISC-машинах загрузку системы можно производить не только с винчестеров, дискет и CD-ROM, но и со стримеров), при этом файловые системы будут созданы автоматически, произойдут установка и инициализация ОС, будет восстановлено все прикладное ПО. От администратора же вообще не требуется выполнять никаких действий. Очень удобно!

До недавнего времени для платформы Intel подобных средств не было. Однако свято место пусто не бывает. Компания Hewlett-Packard разработала технологию «восстановление с помощью одной кнопки» (One-Button Disaster Recovery, OBDR), с эмуляцией стримером загрузочного CD-ROM. Таким образом, систему можно загружать со стримера, поддерживающего технологию OBDR, аналогично тому, как это происходит в случае загрузочных CD-ROM. Фактически функциональные возможности утилит наподобие sysback удалось перенести на платформу ПК. Сейчас технологию OBDR поддерживают стримеры не только от HP, но и от других компаний, причем их список постоянно увеличивается. Поэтому при покупке нового стримера я советую обращать внимание на наличие OBDR. Она значительно облегчит вам жизнь впоследствии.

Единственная проблема с OBDR заключается в том, что программное обеспечение резервного копирования также должно поддерживать эту технологию. К счастью, в последних версиях ARCserveIT и Backup Exec поддержка уже реализована.

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

1. Резервное копирование проводить на периодической основе. В случае обновления или модернизации ПО рекомендуется выполнить внеочередное копирование.

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

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

4. Особо ценные резервные копии (например, для сервера резервирования) следует дублировать, поскольку ленты имеют обыкновение портиться со временем.

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

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

КОПИРОВАНИЕ СУБД И ПОЛЬЗОВАТЕЛЬСКИХ ФАЙЛОВ

Проблемы могут возникнуть и при резервировании и архивировании баз данных. Как показывает практика, резервирование базы данных лучше всего проводить в «холодном» виде, когда перед резервированием БД закрывается. Такое резервирование лучше всего выполнять в ночное время, когда пользователей можно отключать от базы. Однако во многих случаях этот вариант неприемлем. Во-первых, базы данных сейчас нередко достигают в объеме сотен и тысяч гигабайт, поэтому их копирование требует слишком много времени, и даже ночи для этого не хватит. Блокировать же доступ к базе на длительное время могут позволить себе немногие. Во-вторых, нередко СУБД работают в режиме on-line (например, на серверах Internet), и отключение их в принципе невозможно.

Чтобы нивелировать проблемы копирования баз данных, производители систем резервирования поставляют специальные агенты для конкретных СУБД. Большинство агентов рассчитано на поддержку таких СУБД, как Oracle, Informix, Sybase. В свою очередь разработчики мощных СУБД снабжают свои продукты программными интерфейсами резервирования или даже отдельными утилитами резервирования. К сожалению, распространенные системы резервирования поддерживают ограниченное количество основных СУБД ввиду экзотичности остальных (в смысле узости рынка). К сожалению, сами производители СУБД не очень-то стремятся восполнить данный пробел. К тому же огромное количество сетевых приложений опирается на собственные базы данных (например, Lotus Notes), найти для них агенты резервирования также может оказаться непросто.

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

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

Для тех организаций, где задействованы системы иерархического хранения данных HSM, резервное копирование превращается в очень непростую задачу. Каждый уровень HSM необходимо резервировать отдельно. И если проблем с резервным копированием первого уровня обычно не возникает, то резервирование второго и третьего уровня требует принятия специальных мер. Резервное копирование этих уровней производится на тот же тип носителей, на основе которого сформирован данный уровень иерархии. Более подробно о системах HSM и проблемах их резервного копирования можно прочитать в упоминавшейся статье в апрельском номере LAN за 1999 г.

СХЕМЫ РОТАЦИИ

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

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

• одноразовое копирование;
• простая ротация;
• «дед, отец, сын»;
• «Ханойская башня»;
• «10 наборов».

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

Простая ротация подразумевает, что некий набор лент используется циклически. Например, цикл ротации может составлять неделю, когда отдельный носитель выделяется для определенного рабочего дня недели. Полная копия делается в пятницу, а в другие дни — инкрементальные (или дифференциальные) копии. Таким образом, для недельного цикла достаточно иметь пять носителей (если копирование происходит только в рабочие дни, и емкость одного носителя достаточна для копии). После завершения цикла все повторяется сначала, и запись производится на те же самые носители, хотя иногда полные (пятничные) копии сохраняют в качестве архива. Недостаток данной схемы в том, что она не очень хорошо подходит для ведения архива, даже если полные копии сохраняются, поскольку количество носителей в архиве быстро увеличивается. Кроме того, запись (во всяком случае, инкрементальная/дифференциальная) производится на одни и те же носители, что ведет к их значительному износу и, как следствие, увеличивает вероятность отказа.

Схема «дед, отец, сын» (Grandfather, Father, Son) имеет иерархическую структуру и предполагает использование комплекта из трех наборов носителей. Раз в неделю делается полная копия дисков компьютера, ежедневно же проводится инкрементальное (или дифференциальное) копирование. Дополнительно раз в месяц производится еще одно полное копирование. Набор для ежедневного инкрементального копирования называется «сыном», для еженедельного — «отцом», и для ежемесячного — «дедом». Состав ежедневного и еженедельного набора является постоянным и неизменным. В случае ежедневного набора свой носитель (их может быть несколько, если объем информации превышает объем одного носителя) закреплен за каждым рабочим днем (кроме пятницы), а в случае еженедельного набора — за каждой неделей по порядку (т. е. данный набор должен содержать не менее четырех носителей). Ежемесячные носители обычно заново не используются и откладываются в архив. Таким образом, по сравнению с простой ротацией в архиве содержатся только ежемесячные копии плюс последние еженедельные и ежедневные копии. Недостаток данной схемы состоит в том, что в архиве находятся только имевшиеся на конец месяца данные. Как и при схеме простой ротации, ежедневные копии подвергаются значительному износу, в то время как нагрузка на еженедельные копии сравнительно невелика.

Схема «Ханойская башня» призвана устранить некоторые из перечисленных недостатков, но, правда, она имеет свои собственные. Схема построена на применении нескольких наборов носителей, их количество не регламентируется, хотя обычно ограничивается пятью-шестью. Каждый набор предназначен для недельного копирования, как в схеме простой ротации, но без изъятия полных копий. Т. е. отдельный набор включает носитель с полной недельной копией и носители с ежедневными инкрементальными (дифференциальными) копиями. В Таблице 1 приведено расписание для пяти наборов носителей. Каждый следующий по порядку набор используется в два раза реже, чем предыдущий. Таким образом, набор N1 перезаписывается каждые две недели, набор N2 — каждые четыре недели, и т. д. Специфической проблемой схемы «Ханойская башня» является ее излишняя сложность.

Схема «10 наборов», как и следует из названия, рассчитана на использование 10 наборов. Период из 40 недель делится на десять циклов. В течение цикла за каждым набором закреплен один день недели. По прошествии четырехнедельного цикла осуществляется сдвиг номера набора. Иными словами, если в первом цикле за понедельник отвечал набор N1, а за вторник — N2, то во втором цикле за понедельник отвечает набор N2, а за вторник — N3. Такая схема позволяет равномерно распределить нагрузку и, как следствие, износ между всеми носителями.

Схемы «Ханойская башня» и «10 наборов» используются нечасто, так как многие системы резервирования их не поддерживают.

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

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

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

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

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

Хронической проблемой некоторых систем резервирования является слабая поддержка русского языка. Например, как выяснилось, при резервном копировании рабочих мест Windows 95/98 с помощью ARCserve for NetWare русские названия файлов после восстановления теряются.

Прежде чем приобретать систему резервного копирования/архивирования, администратору необходимо убедиться, что для нее имеются агенты для используемых в компании СУБД. Отдельные агенты также необходимы для таких приложений, как Lotus Notes, Novell GroupWise, Microsoft Exchange, не говоря уже о системах наподобие SAP R/3. На практике нередко встречаются случаи, когда поддержка того или иного приложения или БД объявлена, но агент работает только с конкретной реализацией системы резервирования.

ЗАКЛЮЧЕНИЕ

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

Константин Пьянзин — обозреватель LAN. С ним можно связаться по адресу: koka@lanmag.ru.