Планирование стратегии архивирования базы данных

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

• Как следует выполнять архивирование, и в каком объеме?

• Как часто следует архивировать базу данных?

• Как долго следует хранить старые копии базы данных?

• Где следует хранить старые копии базы данных?

При разработке стратегии рекомендуется следовать следующим правилам:

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

• Архивирование должно обязательно производиться непосредственно перед и сразу после внесения изменений в структуру БД. В этом случае пользователь застрахован от возможных потерь данных при некорректных структурных изменениях.

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

• Наиболее актуальный архив (а лучше и часть старых) должен храниться на нескольких конструктивно и энергетически независимых территориально удалённых носителях. Например, на DVD-R, флеш-носителе и внешнем HDD, расположенных в разных помещениях.

• Если используемое прикладное ПО предусматривает функцию архивирования, её также следует использовать. Например, для подсистемы «Отдел кадров» это будет функция выгрузки в отдельные таблицы списка уволенных сотрудников по годам. Сведения подобного рода можно архивировать однократно.

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

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

Восстановление базы данных, архивированной в автономном режиме

Если сбой аппаратуры или ПО привел к необходимости восстановления данных с резервной копии, то при наличии БД, архивированной в автономном режиме, восстановление проводится при помощи следующей последовательности действий:

• Останов HyTech SQL- сервера, управляющего восстанавливаемой БД, если это требуется;

• Подготовка носителя (диска) для восстановления файлов с резервной копии;

• Восстановление БД;

• Запуск HyTech SQL-сервера.

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

В случае, если носитель (диск) работоспособен, и принято решение о восстановлении данных на тот же диск, рекомендуется восстанавливать данные, предварительно переименовав каталог, в котором располагались поврежденные данные. Например, если каталог БД: C:/HYTECH/DB, каталог резервной копии: E:/HYTECH/BACKUP, то следует сначала переименовать каталог C:/HYTECH/DB, например, в C:/HYTECH_OLD/DB, далее создать каталог C:/HYTECH/DB и затем выполнить восстановление с резервной копии. Таким образом, может быть снижен риск записи данных поверх поврежденных блоков диска.

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