3. Частичное резервное копирование

Частичные резервные копии появились в версии SQL Server 2005. Они предназначены для использования в простой модели восстановления с целью повышения гибкости при резервном копировании очень больших баз данных, которые содержат одну или несколько файловых групп только для чтения. Однако частичные резервные копии пригодны для всех баз данных независимо от модели восстановления.

Частичная резервная копия отличается от полной тем, что содержит в себе не все файловые группы. Вместо этого в нее включаются все данные первичной файловой группы, всех файловых групп с режимом доступа «чтение и запись» и всех указанных дополнительных файлов. Частичные резервные копии могут оказаться полезны в тех случаях, когда необходимо исключить файловые группы только для чтения. Частичная резервная копия базы данных, открытая только для чтения; содержит только первичную файловую группу.

Для создания частичной разностной резервной копии применяется инструкция BACKUP. Она должна содержать параметры DIFFERENTIAL и READ_WRITE_FILEGROUPS. Если последняя частичная резервная копия (основа для разностной копии) содержит файлы или файловые группы только для чтения, необходимо указать каждую из них в инструкции. Синтаксис инструкции BACKUP для создания частичной разностной резервной копии:

BACKUP DATABASE database_name READ_WRITE_FILEGROUPS [ , <file_filegroup_list> ] TO <backup_device> WITH DIFFERENTIAL

4. Резервное копирование журнала транзакций

Журнал транзакций представляет собой специальный файл, необходимой любой базе данных для надлежащего функционирования. В нем содержатся записи журнала, создаваемые в процессе ведения журнала, и журнал используется для повторного чтения этих записей во время восстановления (или любого другого, упоминавшегося ранее, использования процедуры ведения журнала). Так же, как пространство, занятое собственно записями журнала, транзакция в журнале транзакций резервирует также пространство для любых потенциальных записей журнала, которые потребовались бы в случае необходимости отменить транзакцию и выполнить откат. Этим объясняется поведение, которое можно наблюдать, когда, например, для транзакции, обновляющей 50 МБ данных в базе данных, на деле в журнале транзакций может потребоваться пространство в 100 МБ.

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

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

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

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

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

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

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

Чтобы восстановить базу данных на момент точки сбоя, нужна неповрежденная цепочка журналов. Непрерывная последовательность резервных копий журналов должна следовать до точки сбоя. Точка начала этой последовательности зависит от применяемого типа резервной копии: резервная копия базы данных, частичная резервная копия или резервная копия файлов. В случае резервной копии базы данных или частичной резервной копии последовательность резервных копий журнала должна начинаться от конца резервной копии базы данных или частичной резервной копии. В наборе резервных копий файлов последовательность резервных копий журналов должна следовать от начала полного набора резервных копий файлов.

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

Для создание резервной копии журнала транзакций выполните инструкцию BACKUP LOG, указав следующее:

• имя базы данных, которой принадлежит журнал транзакций, резервную копию которого необходимо создать;

• устройство резервного копирования, на которое записывается резервная копия журнала транзакций.

Можно также указать следующее:

• предложение INIT для перезаписи существующих данных на носителе резервных копий и записи файла резервной копии как первого файла на этом носителе. Если на носителе нет заголовка, то он также будет автоматически записан;

• предложения SKIP и INIT, служащие для перезаписи носителя резервной копии (даже несмотря на наличие резервных копий, срок действия которых еще не истек), или несовпадение имени носителя с именем на носителе резервной копии;

• предложение FORMAT, которое инициализирует впервые используемый носитель резервных копий и перезаписывает заголовок носителя, если таковой существует.

Если указано предложение FORMAT, то предложение INIT не требуется.

Будьте предельно осторожны, используя предложения FORMAT и INIT инструкции BACKUP, так как они удаляют все резервные копии, сохраненные ранее на носителе резервных копий.