7.4.1.Резервное копирование

7.4.1.1.Архивирование данных

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

Главный вопрос при архивировании данных: частота резервного копирования. Когда администратор БД архивирует информацию, производительность работы пользователем с БД снижается, поэтому необходимо определить рациональный режим копирования/восстановления данных.

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

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

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

SQL Server имеет механизм автоматического отслеживания изменений данных. Однако если архивирование происходит редко, полноценная работа с БД не возможна.

Кроме пользователя БД необходимость резервного копирования актуальна для БД MASTER и MSDB.

Master – единственный способ резервного копирования для БД – это полное копирование. Она содержит информацию о пользователе, объекте БД, которые являются общими для экземпляра сервера SQL, объект устраивает резервное копирование, системные и пользовательские ошибки и связанные серверы.

MSDB – хранит информацию о работе служб SQL Server Agent, схему выполнения всех операций резервного копирования БД.

7.4.1.2.Схема резервного копирования

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

В качестве носителя используют: стримеры (магнитные ленты), диск, сетевой ресурс, именованные каналы.

Стример – самый дешевый способ хранения. Однако использование этого накопителя не целесообразно, если требуется высокая скорость обработки данных и объем архивированных данных заранее неизвестен. Одним из способов повышения производительности является использование двух накопителей одновременно. Однако необходима дополнительная сила для обслуживания устройства.

Диск. В качестве носителя может выступать любой диск, с которым ОС способна работать напрямую. При создании резервной копии наиболее часто в качестве носителя выбирают жесткий диск (быстрый и надежный способ – не стоит использовать с файлами данных и транзакций).

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

Именованные каналы используются, если SQL Server применяет собственное приложение для обработки архивов. SQL Server «закачивает» данные в канал, а приложение получает из него информацию.

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

Информация об устройстве резервного копирования находится в системной таблице sysdevices. Если резервное копирование создается непосредственно в файл, то информация о нем в таблицу не заноситься, и повторно использовать их нельзя.

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

sp_addumpdevice ‘disk’, ‘BackupDevice’, ‘C:\SQL\Full.back’ //создает дисковое устройство резервного копирования с логическим именем BackupDevice, используя файл C:\SQL\Full.back

sp_addumpdevice ‘tape’, ‘TapeBackupDevice’, ‘\\.\Tape0’ //создает на стримере устройство резервного копирования с логическим именем TapeBackupDevice, используя ленточный накопитель 0, т.е. первый ленточный накопитель системы

sp_addumpdevice ‘disk’, ‘BackupDevice’, ‘\\Pion\SQL\TLog.bak’ //создает дисковое устройство резервного копирования с логическим именем BackupDevice, используя файл