Разностная копия

Разностное, или дифференциальное резервное копирование (differential database backup) было разработано с целью уменьшения времени, необходимого для получения копии базы данных. В основе дифференциальной копии лежит отсле­живание изменений, вносимых пользователями в базу данных. Создание дифференциальной копии состоит из двух этапов:

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

создание собственно дифференциальной копии.

Полная копия базы данных является отправной точкой, начиная с которой система может отслеживать изменения. Изменения отслеживаются на уровне страниц. Каждая страница имеет флаг архивирования, который сбрасывается при создании полной копии и устанавливается, если данные на странице были изменены. Это можно сравнить с атрибутом архивирования для файлов. При создании резервной копии атрибут снимается, но если файл изменяется, то система автоматически устанавливает его. Программа резервного копирования ищет все файлы с установленным атрибутом архивирования и копирует их. Аналогично ведет себя и подсистема резервного копирования QL Server 2000. Однако необходимо отметить, что флаг архивирования для страниц данных снимается только при создании полной копии данных. Это означает, что при создании последовательно нескольких дифференциальных копий каждая следующая будет полностью включать страницы, которые были включены в предыдущую копию плюс все страницы, измененные со времени создания предыдущей копии. Поэтому актуальна только самая последняя дифференциальная копия. Достаточно применить ее после восстановления полной резервной копии, чтобы целиком восстановить систему.

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

Копия журнала транзакций

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

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

Решением подобных проблем является применение резервного копирования журнала транзакций(transaction log backup). Этот тип резервного копирования по­зволяет сохранять информацию обо всех транзакциях, выполненных в базе данных. В итоге резервная копия содержит непрерывную цепочку изменений, которые претерпели данные со времени последнего архивирования. Такая цепочка позволяет восстановить систему в состоянии, в котором она была в любой момент времени, и этот момент отображен в резервной копии. При восстановлении резервной копии журнала транзакций SQL Server 2000 последовательно выполняет все изменения, выполненные пользователями в базе данных.

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

Если вы планируете применять резервное копирование журнала транзакций, необходимо следить за тем, чтобы в нем отображалась информация обо всех транзакциях, выполненных в базе данных, и чтобы эта информация была непрерывной. При этом нельзя устанавливать для базы свойство trunc. log on chkpt (Truncate transaction log on checkpoint). При установке этой опции SQL Server 2000 периодически удаляет из журнала транзакций информацию об уже завершенных (неактивных) транзакциях. Данная операция называется усечением (truncate). Усечение приведет к тому, что информация о транзакциях окажется потерянной, и будет нарушена непрерывность цепочки изменений, отображаемой в резервной копии журнала транзакций.

При резервном копировании журнала транзакций SQL Server 2000 автоматически выполняет усечение журнала транзакций после завершения создания архива. То есть размер журнала транзакций будет автоматически поддерживаться на нормальном уровне. Еще раз заметим, что ни пользователь, ни SQL Server 2000 не должны выполнять усечения журнала транзакций. Иначе целостность информации об изменениях в базе данных будет нарушена. Операция усечения должна выполняться только после завершения создания резервной копии журнала транзакций. Следующий архив будет содержать только те транзакции, которые были выполнены после завершения создания последней резервной копии журнала транзакций. Между операциями создания полной или разностной копии базы данных могут выполняться несколько операций архивирования журнала транзакций. Но при восстановлении базы данных необходимо последовательно применять каждую из копий журнала транзакций. В отличие от дифференциальной копии, которая отображает все изменения, сделанные в базе данных после создания полной последней копии, резервная копия журнала транзакций отображает только цепочку изменений, сделанных после последней операции архивирования журнала транзакций. Это происходит потому, что SQL Server автоматически осуществляет усечение журнала транзакций после завершения создания его резервной копии. То есть журнал транзакций просто не содержит никакой информации о транзакциях, выполненных ранее.

При создании резервной копии журнала транзакций SQL Server 2000 включает в архив только те транзакции, которые были завершены к моменту окончания создания резервной копии. Если транзакция была завершена на 99% к моменту создания архива, то она все равно не будет включена в резервную копию. Одна­ко при выполнении усечения журнала транзакций эта транзакция не будет удалена из журнала и при следующем архивировании журнала транзакций будет включена в архив.

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