Планирование резервного копирования
При разработке системы резервного копирования одной из важнейших составляющих является выработка правильного набора требований к комплексу резервного копирования. Постарайтесь учесть все аспекты резервного копирования, сделайте два варианта сметы – минимально необходимый и желательный, и обоснуйте руководству организации необходимость дополнительного финансирования, связанного с резервным копированием данных, критичных для самого существования организации. Постарайтесь реализовать хотя бы минимальный вариант резервного копирования. Если вы работаете в банке или в другом подобном учреждении, где данные стоят очень дорого, то обычно удается реализовать схему резервного копирования по максимуму. Добейтесь письменного одобрения ваших действий (лучше всего приказа по организации), чтобы не было отступлений от утвержденной сметы.
Основным фактором, определяющим стоимость системы резервного копирования, является объем архивируемых данных и время, выделяемое на эту процедуру. Чем больше объем данных, обрабатываемых системой резервного копирования в единицу времени, тем дороже получается создаваемая система. Если на проведение резервного копирования ваше серверное хозяйство может выделить ограниченный интервал времени, или если оно функционирует круглосуточно, при планировании системы резервного копирования следует учитывать это обстоятельство, поскольку изменение резервируемых данных до завершения создания резервной копии приводит к получению некорректной резервной копии системы. В том случае, если вы можете остановить работу сервера либо по окончании рабочего дня сервер не используется, процесс резервирования становится тривиальным и, как правило, достаточно дешевым.
Ежедневные процедуры копирования должны выполняться в то время, когда данные находятся в некотором стабильном состоянии, например после окончания рабочего дня. Если не представляется возможным исключить сервер на время создания резервной копии из производственного процесса, руководство фирмы должно знать о возможных осложнениях – обычно это не совсем корректное сохранение информации. В серьезных серверах баз данных об этой проблеме знают, и существуют методы получения точной резервной копии баз данных.
Большинство систем резервного копирования строится на использовании либо команды сгоп, либо собственных утилит автоматического вызова программ по установленному расписанию. Как правило, они позволяют разрабатывать и поддерживать относительно сложные графики проведения работ. Кроме того, системы резервного копирования могут предусматривать прямое взаимодействие с приложениями с целью запуска их собственных механизмов резервного копирования. Зачастую для целей резервного копирования используются программы и скрипты собственной разработки, учитывающие особенности функционирования вычислительной среды организации.
Выбор схемы хранения резервных данных является еще одним фактором, оказывающим существенное влияние на стоимость создаваемой системы резервного копирования. Схема хранения должна учитывать специфику организации, а также требования, устанавливаемые контролирующими органами (например для банков требования Центрального банка в отношении резервирования данных очень высоки). Кроме того, при выборе схемы хранения должны учитываться и требования, сформулированные в плане восстановления после аварий.
Большинство систем резервного копирования обеспечивают эффективное использование носителей информации за счет организации, по крайней мере, двух независимых уровней хранения данных. Так, полная копия содержит копии содержимого всех без исключения файлов системы. При инкрементном копировании в архив помещаются только те файлы, которые были изменены с момента создания последней полной или инкрементной копии. Используя различные алгоритмы резервного копирования, можно разработать стратегию резервного копирования, которая сбалансирует требования к эффективности и надежности.
Приведем пример схемы резервного копирования, которая может быть реализована в достаточно крупной фирме. Все данные копируются по субботам. С воскресенья по пятницу выполняется создание инкрементных копий. Носители информации с еженедельными и ежедневными копиями возвращаются на перезапись через месяц.
Формат хранения резервных копий должен быть таким, чтобы резервную копию при желании можно было развернуть на другой операционной системе (например, Windows). Рекомендуется пользоваться программами tar и gzip, аналоги которых существуют практически в любой операционной системе. Это позволит в случае надобности извлечь нужные файлы практически где угодно.
Чтобы не превратить библиотеку резервных копий в ненужную свалку данных, необходимо озаботиться составлением каталогов данных резервного копирования. Обычно в более или менее серьезных пакетах резервного копирования присутствуют функции ведения каталогов.
Базовые утилиты, в том числе tar и cpio, не позволяют создавать подобные каталоги данных резервного копирования. Если для копирования применяются именно они, то каталоги придется вести либо с помощью специально созданного программного обеспечения, либо вручную.
Некоторые приложения для корректного функционирования требуют абсолютной согласованности наборов данных. Так, системы управления базами данных обычно имеют собственные средства резервного копирования. Поскольку принадлежащие такого рода системам данные часто находятся в состоянии непрерывного изменения, задача фиксирования их согласованного состояния выходит за рамки возможностей программ типа tar, cpio и dump.
Для разрешения указанной проблемы разработчики обычно включают в подобные системы специальное программное обеспечение, способное зафиксировать в копии согласованное состояние их данных. В API системы могут включаться необходимые вызовы, или администраторам предоставляются специализированные сценарии, вызываемые из приложения. Поскольку такие приложения и системы копирования не имеют единого интерфейса, потребуется самостоятельно создать связующие программы промежуточного уровня.
В тех случаях, когда деловой процесс позволяет останавливать работающие с базами данных приложения, а сами базы данных периодически закрываются, может применяться и обычная схема резервного копирования.
Те серверы баз данных, которые поддерживают репликацию, также нуждаются в создании резервных копий. Репликация не защищает от случайного или преднамеренного удаления данных. Кроме того, сетевые соединения между реплицируемыми системами могут отказывать, что вызывает нарушение согласованности данных.
Стратегия резервного копирования баз данных должна разрабатываться совместно с администраторами баз данных. В одних случаях может оказаться приемлемым разрешить администраторам баз данных выполнять процедуры резервного копирования и восстановления вручную. В других случаях эти действия должны будут выполняться при участии системного администратора.
Что такое резервное копирование
Основная идея резервного копирования – создание копий всего, что установлено на вашей системе, с некоторыми исключениями. Основными исключениями, не включаемыми в резервные копии, являются:
• файловая система /proc, т. к. она содержит только данные, которые ядро генерирует во время работы операционной системы, и нет никакого смысла сохранять их;
• файловая система /mnt, поскольку в нее монтируются сменные носители – CD-ROM, дискеты и т. п.;
• сетевые каталоги – смонтированная файловая система NFS, Samba и прочие виды сетевых данных;
• программное обеспечение, которое может быть легко повторно установлено. Здесь надо иметь в виду, что оно может иметь конфигурационные файлы, которые необходимо копировать, чтобы не выполнять работы по их настройке позже.
Носители данных
Тип носителей для резервного копирования сильно зависит от ваших финансовых возможностей и объема сохраняемой информации. Совершенно нелогично покупать дорогую магнитооптику, если объем резервируемой информации не превышает одного-двух мегабайт за неделю. Рассмотрим носители информации и приводы, которые можно использовать в целях резервного копирования.
Дискета
Пожалуй, самое простое решение для небольших резервных копий и самое дешевое – дискеты стоят весьма дешево. Однако с точки зрения надежности – решение не выдерживает никакой критики. У каждого пользователя есть печальный опыт потери информации из-за некачественных дискет, даже если применять дисководы только известных производителей (Panasonic, Sony, Теас) и хорошие дискеты фирм Verbatim, TDK, BASF. Помимо всего прочего – дискеты боятся магнитных полей.
Iomega Zip
Накопители Iomega Zip существуют в нескольких вариантах – емкостью 40, 100 и 250 Мбайт. Достаточно большая скорость обмена, хорошая сохранность данных, однако весьма высокая стоимость самого привода и носителей информации, а также небольшая по современным меркам емкость дисков не способствуют широкому распространению этих устройств.
