Введение в дисциплину «Безопасность систем баз данных». Теоретические основы построения реляционных баз данных. Верификация баз данных и проведение аудита в СБД. Распределенные базы данных, страница 60

Резервное копирование (архивирование) – это периодически выполняемая процедура получения копии БД и журнала транзакций на отдельном от СУБД носителе.

Необходимость создания резервных копий может быть обусловлена:

·  возможностью порчи файлов БД (в результате аппаратных сбоев, ошибок в работе ОС, случайных и умышленных действий пользователей);

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

Рассмотрим механизмы резервного копирования, применяемые в SQL Server 2005.

Резервная копия БД MS SQL Server – это либо полная копия содержимого БД, либо копия множества отдельных страниц, либо копия журнала транзакций, хранящаяся в слабо сжатом виде на специальном устройстве резервного копирования. В качестве устройства может быть выбран жесткий диск (или массив дисков), стример или ленточная библиотека.

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

SQL Server поддерживает четыре способа резервного копирования:

·  создание полной резервной копии данных;

·  создание разностной копии данных;

·  копирование журнала транзакций;

·  копирование файлов и групп файлов.

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

7.1.1. Полная резервная копия

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

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

Следующие два вида резервного копирования позволяют фиксировать «промежуточные» состояния БД без существенного снижения производительности сервера.

7.1.2. Разностное резервное копирование

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