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

Наверное, у многих слова лента и накопитель вызовут ностальгические воспоминания о хранении данных на магнитофонных кассетах в начале 90-х или же о многокилометровых бобинах, мерно крутящихся в шкафах размером в человеческий рост. А тем временем, современные стримеры (streamer - поточный накопитель) - это малогабаритные высокоскоростные устройства, использующие интерфейс SCSI, полностью управляемые программно. А некоторые модели оснащены устройством для автоматической смены кассет (changer).

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

При этом цены на стримеры и кассеты отнюдь не являются астрономическими. Размеры же их вполне компактны даже в сравнении с магнитофоном.

Суть резервного копирования заключается в периодическом копировании важных данных на магнитную ленту. Счастливчики, которые ни разу не теряли данных из-за "падения" жёсткого диска, очевидно, существуют, но их радость определённо не может перевесить горе тех, кто хоть раз это испытал.

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

Какую схему выбрать, зависит от объёма доступных кассет и объёма данных, которые нужно копировать. Иногда, но весьма не часто, можно довольствоваться периодическим полным копированием.

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

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

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

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

С инкрементальным копированием всё наоборот - ленты тратится меньше, но времени на восстановление уйдёт больше.

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

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

Процедура резервного копирования может быть почти полностью автоматизирована с помощью программ Backup в ОС Windows и tar в ОС Linux. Как правило, ручная работа при хорошо поставленной системе резервного копирования сводится к нечастой смене кассет. А если использовать привод, который поддерживает загрузку нескольких кассет одновременно, то менять магазин с кассетами придётся только раз в неделю.

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

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

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

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

Кассеты могут объединяться в логические группы (pools), которые позволяют не перепутать кассеты при их смене. Опасность "затереть" важные данные практически отсутствует, программа просто откажется записывать данные на ошибочно вставленную кассету. Эта же система группировки носителей позволяет администратору не тратить время на ручной учёт носителей - он будет получать по e-mail конкретные запросы вида "требуется такая-то кассета", после установки кассеты процесс копирования будет продолжен.

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

Аналогично дело обстоит и с почтовым сервером - если пользователи будут получать доступ к своей почте по протоколу IMAP4 или MAPI, то существенно повышается надёжность хранения почтовых ящиков и одновременно упрощается задача их резервного копирования.

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

© 2002 Алексей ГРЕЧАНИНОВ