Типы резервного копирования

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

· полная копия;

· разностная копия;

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

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

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

· создание и удаление файлов базы данных;

· создание индексов;

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

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

Полная копия базы данных (database backup) является стандартным типом резервного копирования. Этот тип резервирования предполагает полное копирование всей информации, имеющейся в базе данных. В качестве приемника данных может выступать либо обычный файл, либо специальное устройство резервного копирования, такое, как стример, CD или zip-диск.

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

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

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

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

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

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

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

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

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

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

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

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

Резервное копирование файлов и групп файлов. Как известно, база данных состоит из одного или более файлов данных и одного или более файлов журнала транзакций. Иными словами, любая база данных состоит минимум из двух файлов. Ни полное, ни резервное копирование не позволяют архивировать только часть данных, например, только данные без индексов или только столбцы типа image, text и ntext. Резервная копия журнала транзакции отображает лишь операции изменения данных.

SQL Server 2000 позволяет выполнять частичное архивирование данных. Для этого администратор должен использовать копирование файлов или групп файлов. Такой подход позволяет контролировать диапазон архивируемых данных вплоть до конкретного столбца таблицы. В основе этого подхода лежит возможность привязывания таблицы или даже отдельного столбца к конкретному файлу или группе файлов. Все данные, принадлежащие столбцу, будут размешаться только в указанном файле или группе файлов. Обычно к файлу или группе файлов привязываются либо таблицы целиком, либо столбцы с типом данных image, text и ntext, требующие значительных ресурсов для их обработки.

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

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

В некоторых случаях создание полной копии базы данных невозможно, так как необходимо обеспечить практически круглосуточную работу сервера в течение семи дней в неделю. У администратора имеется в распоряжении всего два-три часа в сутки. С помощью архивирования файлов или группы файлов администратор может разбить архивирование большой базы данных на несколько менее “тяжелых” операций, занимающих меньше времени. Создание резервной копии всей базы данных можно разбить на несколько операций архивирования отдельных файлов базы данных. В этом случае архивирование базы данных может растянуться на несколько суток. В принципе этот процесс может быть непрерывным. По завершении архивирования последнего файла SQL Server 2000 может начать все заново.

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