Обеспечение резервного копирования
Поскольку обычно базы данных бывают очень большими, и в них хранится исключительно важная информация, правильная организация резервного копирования данных является очень важным вопросом. Объем вовлеченных в этот процесс данных обычно огромен, особенно по отношению к размеру и обычной скорости устройств резервного копирования. Просто непрактично осуществлять дамп базы данных объемом 20 Гбайт на магнитную ленту 4 мм, работающую со скоростью500 Кбайт/с: это займет примерно 12 часов. В этой цифре не учтены даже такие важные для работы системы соображения, как обеспечение согласованного состояния базы данных и готовность системы.
Составить расписание для резервного копирования системы, которая используется, главным образом, в течение нормального рабочего времени, обычно сравнительно просто. Для выполнения процедур резервного копирования после завершения рабочего дня часто используются скрипты. В некоторых организациях эти процедуры выполняются автоматически даже без привлечения обслуживающего персонала, в других в неурочное время используют операторов. Для выполнения автоматического резервного копирования без привлечения обслуживающего персонала требуется возможность его проведения в рабочем режиме (режиме on-line).
Если система должна находиться в рабочем режиме 24 часа в сутки или если время, необходимое для выполнения резервного копирования превышает размер доступного окна (временного интервала), то планирование операций резервного копирования и конфигурирование соответствующих средств значительно усложняются.
В некоторых случаях необходимо выполнять резервное копирование "врежиме on-line", т. е. в то время, когда база данных находится в активном состоянии с подключенными и работающими пользователями.
При выполнении резервного копирования базы данных предполагается, что она находится в согласованном состоянии, т. е. все зафиксированные обновления базы данных не только занесены в журнал, но и записаны также в таблицы базы данных. При реализации резервного копирования в режиме on-line возникает проблема: чтобы резервные копии оказались согласованными, после того как достигнута точка согласованного состояния базы данных и начинается резервное копирование, все обновления базы данных должны выполняться без обновления таблиц самой базы до тех пор, пока не завершится ее полное копирование.
Большинство основных СУБД обеспечивают возможность резервного копирования в режиме on-line.
Продолжительность процедур резервного копирования, возможно, является наиболее важным вопросом для организаций с большими базами данных (объемом более 10 Гбайт), и выбор методики резервного копирования может определяться именно этим. Резервное копирование небольших баз данных легко осуществляется при наличии всего одного накопителя на магнитной ленте Exabyte или DAT. Хотя многие выпускаемые в настоящее время накопители на МЛ позволяют копировать данные со скоростью примерно 1,25 Гбайт в час, для больших баз данных это, очевидно, неприемлемо. Для увеличения пропускной способности несколько устройств могут работать параллельно, хотя конфликты по ресурсам делают этот способ недостаточно эффективным при использовании одновременно более трех-четырех НМЛ.
Некоторые НМЛ на ленте 8 мм с аппаратной компрессией способны обеспечивать скорость до 6 Гбайт/с, т. е. более чем вдвое превышают скорость стандартных устройств. Часть из этих устройств имеют емкость до 40 Гбайт, но более типичной является емкость 10-14 Гбайт. Для очень больших баз данных в качестве устройств резервного копирования применяются библиотеки, построенные на базе стандартных накопителей. В этом случае немаловажными являются такие параметры, как количество устройств чтения/записи в библиотеке, количество используемых лент, наличие устройства чтения BarCode для быстрого поиска нужной ленты. Современные ленточные библиотеки имеют емкость более одного терабайта (двух терабайт с аппаратной компрессией) и обеспечивают скорость копирования до 40 Гбайт в час.
Если недоступно устройство, которое поддерживает аппаратную компрессию, то стоит рассмотреть возможность использования программной компрессии. Скорость резервного копирования обычно определяется скоростью физической ленты, поэтому любой метод, сокращающий количество данных, которые необходимо записать на ленту, должен исследоваться, особенно при использовании быстрых ЦП.
Базы данных являются хорошими кандидатами для компрессии, поскольку большинство таблиц и строк включают значительную часть свободного пространства(обычно используются даже коэффициенты заполнения, обеспечивающие определенный процент свободного пространства с целью увеличения производительности).Некоторые таблицы могут содержать также текст или разбросанные поля двоичных данных и готовы для компрессии.
Перспективным средством резервного копирования и архивирования информации считаются также магнитооптические устройства. Правда, пока они имеют сравнительно небольшую вместимость (до 2,6 Гбайт) и сравнительно высокую стоимость носителей.
Простым, но эффективным способом сокращения времени резервного копирования является выполнение копирования на отдельный зеркальный диск. Если зеркальная копия сделана непосредственно после контрольной точки, или после того, как база данных выключена, она действительно становится дисковой резервной копией on-line, которая сама может быть скопирована в любое удобное время. Можно даже выполнить рестарт базы данных, чтобы продолжить нормальную обработку, хотя с меньшей избыточностью. Если доступно достаточное количество дисковых накопителей, то может быть использован и второй набор зеркальных дисков, что позволяет сохранить полное зеркалирование, даже когда один набор зеркальных дисков отключается (во время нормальных операций диски будут зеркалироваться по трем направлениям). В этом случае резервное копирование в режиме on-line может продолжаться после копирования на ленту, что обеспечивает в случае необходимости очень быстрое восстановление. Этот дополнительный набор зеркальных дисков мог бы быть заново подключен перед следующей контрольной точкой, обеспечив достаточно времени (примерно 30 минут), которое позволит этому набору зеркальных дисков синхронизоваться с зеркальными дисками, работавшими в режиме on-line.
Большинство пользователей выполняют полное резервное копирование ежедневно. Полагая, что резервное копирование выполняется на тот случай, когда понадобится восстановление, важно рассмотреть составляющие времени восстановления.
Оно включает время перезаписи (обычно с ленты) и время, которое требуется для того, чтобы выполнить изменения, внесенные в базу данных с момента резервного копирования. Учитывая необходимость средств такой "прокрутки" вперед, очень важно зеркалировать журналы и журналы архивов, которые и делают этот процесс возможным.
В рабочей среде, где большое количество транзакций выполняют записи в базу данных, время, требуемое для выполнения "прокрутки" вперед от последней контрольной точки может существенно увеличить общее время восстановления. Это соображение само по себе существенно для определения частоты резервного копирования.
Выполнение процедур резервного копирования должно соответствующим образом отслеживаться, чтобы гарантировать, что они завершились успешно. Также важно документировать и тестировать процедуры восстановления. Момент аварии- не слишком удачное время для обнаружения того, что в стратегии резервного копирования пропущены некоторые ключевые элементы.
