Главная » Microsoft SQL Server, Базы данных » Резервирование базы данных

0

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

Устройства резервирования

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

?               Дисковая подсистема. Резервирование может выполняться как на локальный диск (желательно в дисковой подсистеме, отличной от той, где хранятся файлы базы данных), так и на жесткий диск другого сервера с использованием универсального соглашения об именовании. Для сохранения файла архива на удаленном сервере учетная запись SQL Server должна иметь соответствующие привилегии.

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

?               Магнитная лента. SQL Server позволяет резервировать данные напрямую на большинство лентопротяжных устройств.

Некоторые компании предлагают сторонние продукты резервирования данных На заметку SQL Server, использующие именованные каналы. Несмотря на то что эти программы могут показаться вам привлекательными, советую все же ознакомиться и со встроенными методами восстановления SQL Server, прежде чем принимать решение относительно выбора стратегии резервирования.

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

Хранение и ротация резервных копий

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

Чаще всего используют следующую стратегию. Используется набор из пяти магнитных лент для еженедельной полной резервной копии и еще один набор из шести магнитных лент для ежедневных дифференцированных копий. Обычно эти ленты маркируются следующим образом: Неделя!, Неделя2 и т.д. и соответственно Понедельник, Вторник,…, Суббота.

Еще одним отличным методом ротации магнитных лент является так называемый палиндром. Палиндромом называют слово, фразу или число, которое в прямом и обратном порядке читается одинаково, например около Мити молоко или 123454321. Некоторые числа, будучи перевернутыми и сложенными сами с собой, дают в результате палиндром, например 236+632=868. У палиндромов богатая история. Еще в Древней Греции писали на фонтанах “Nispon anomemata me monan opsin”, что в переводе означает “смывай грехи, как моешь свое лицо”.

Используя четыре ленты, маркированные буквами от А до Г, ротацию лент можно организовать следующим способом: АБВГВБА АБВГВБА…

В качестве альтернативы метод палиндрома можно организовать так, чтобы каждая следующая буква представляла относительно больший интервал. Например, букву А можно использовать для ежедневных архивов, Б — для еженедельных, В — для ежемесячных, Г — для ежеквартальных и т.д.

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

Выполнение резервного копирования в Management Studio

Первая резервная копия должна быть полной; с нее начинается цикл резервирования базы данных.

можно выполнить в утилите Management Studio. Для этого нужно выделить базу данных, щелкнуть правой кнопкой мыши и выбрать в контекстном меню пункт Tasks^Backup. Откроется окно Back Up Database, показанное на рис. 36.3.

Рис. 36.3. Окно Back Up Database имеет две страницы: одну с общими настройками, другую — с параметрами

Источник данных резервного копирования конфигурируется на странице General.

?               Database. Резервируемая база данных. По умолчанию это текущая база данных в Management Studio.

?               Backup. Тип резервного копирования: full, differential или transaction-log. Если в базе данных установлена простая модель восстановления, то вариант transaction-log будет недоступным. Если выбирается полное или дифференцированное резервирование, то резервная копия может создаваться для всей базы данных или для выделенных файлов или файловых групп.

Все остальные элементы страницы предназначены для определения приемника резервной копии.

?               Name. Обязательное имя резервной копии.

?               Description. Необязательная дополнительная информация о резервной копии.

?               Expiration Date. SQL Server не допустит замещение данного архива другим до этой даты истечения срока годности.

?               Destination. Файл назначения на ленте или диске. Если текущий файл назначения не корректен, удалите его и добавьте корректный.

?               Contents. Список резервных копий, уже существующих в файле назначения.

На странице Options представлены следующие параметры.

?               Append to existing backup set или Overwrite all existing backup sets. Этот параметр определяет, будет ли новая резервная копия добавлена в существующий файл архива, или будет инициализирован носитель и в него будет помещен новый набор резервных копий. Дополнительно SQL Server может проверить даты истечения срока годности переписываемых наборов.

?               Verify backup upon complution. Несмотря на свое название, этот параметр не сравнивает данные резервной копии с базой данных; также он не проверяет целостность архива. Он позволяет просто получить подтверждение о завершении формирования набора резервных копий и о том, что файл читаемый. Как бы там ни было, я всегда устанавливаю этот параметр.

О         Eject tape after backup. Извлекает ленту из привода, что позволяет случайно не переписать существующий файл архива.

?               Remove inactive entries from the log. Это эквивалент Management Studio операции сжатия журнала транзакций. Как только журнал транзакций был успешно заархивирован, из него удаляются все транзакции, чтобы файл журнала не разрастался бесконечно.

?               Check media set name and backup set expiration. Проверяет носитель резервной копии на корректность.

?               Backup set will expire. Установка срока годности резервной копии. До истечения указанного срока данные архива не могут быть замещены другими.

?               Initialize and labels. Указывает серверу инициализировать ленту и присвоить ей метку.

в программном коде

Команда backup предлагает больше вариантов резервного копирования, чем утилита Management Studio. Использование этой команды может оказаться полезным для ручной

сборки заданий агента SQL Server Agent, что считается более правильным, нежели использование плана обслуживания Maintenance Plan Back Up Task.

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

BACKUP DATABASE имя_базы_даиных ТО DISK = ‘ путь_к_файлу’

WITH

NAME = 1 имя_архива1

Следующая инструкция резервирует базу данных СНА2 в файл на диске и присваивает архиву имя СНА2Backup:

BACKUP DATABASE СНА2

ТО DISK = ‘e:\Cha2Backup.bak’

WITH

NAME = 1CHA2Backup 1 Будет получен следующий результат:

Processed 200 pages for database 1CHA2′, file 1CHA2′ on file 1.

Processed 1 pages for database 1CHA2′, file ‘CHA2_log’ on file 1.

BACKUP DATABASE successfully processed 2 01 pages in 0.316 seconds (5.191 MB/sec).

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

?               Таре. Чтобы создавать резервную копию на магнитной ленте, а не на диске, используйте параметр ТО ТАРЕ и укажите место размещения архива.

ТАРЕ = ‘ \ \ .\TAPE01

?               Differential. Указывает команде выполнить дифференцированное резервное копирование, а не полное, принятое по умолчанию. Следующая команда выполнит дифференцированное резервирование базы данных СНА2:

BACKUP DATABASE СНА2

ТО DISK = ‘e:\Cha2Backup.bak’

WITH

DIFFERENTIAL,

NAME = ‘CHA2Backup 1

?               Для выполнения резервного копирования отдельных файлов данных или файловой группы перечислите их после имени базы данных. Этот прием поможет правильно организовать резервные копии. Например, из соображений удобства резервирования учебная база данных OBXKites хранит статические таблицы в одной файловой группе, а активные таблицы в другой — первичной.

?               Password. Если резервная копия создается на незащищенной ленте, настоятельно рекомендуется защитить архив паролем. Пароль применяется к конкретному экземпляру архива.

Команда резервного копирования имеет ряд дополнительных, менее важных параметров.

?               Description. Этот параметр идентичен одноименному полю Management Studio.

?               ExpireDate. Идентичен Management Studio. До истечения указанного срока данные архива не могут быть замещены другими.

?               RetainDays. Количество дней (целое число) до того, как SQL Server может заместить резервную копию.

?               Stats = %. Указывает серверу информировать о ходе выполнения резервного копирования с указанным шагом (в процентах). По умолчанию принят шаг в 10%.

?               BlockSize. Установка размера блока в архиве. Для резервных копий, сохраняемых на диске, данный параметр не нужен. Для копий, создаваемых на ленте, он тоже может не понадобиться, однако он способен решить некоторые проблемы совместимости. При создании резервных копий на диске автоматически применяется размер блока, установленный в операционной системе Windows. Если объем диска больше 2 Гбайт, то размер блока обычно устанавливается в 4096 байт. Если резервную копию, создаваемую на диске, впоследствии планируется записать на компакт-диск, то лучше установить размер блока в 2048 байт.

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

?               MediaDescription. Записывает необязательное описание носителя.

?               MediaPassword. Создает необязательный пароль и применяет его ко всему носителю (дисковому файлу или магнитной ленте). Этот пароль также может быть создан при первом создании носителя. Если пароль на носителе уже установлен, то он должен указываться при каждом последующем к нему обращении (при добавлении дополнительных резервных копий и при восстановлении данных).

?               Init /NoInit. Инициализирует ленту или файл на диске, переписывая все существующие наборы резервных копий на носителе. SQL Server не допустит инициализации, если у любого из архивов на носителе еще не истек срок годности или если не истекло количество дней его хранения. По умолчанию используется параметр No I nit.

?               NoSkip/Skip. Этот параметр позволяет пропустить проверку имени и срока годности, что при обычных условиях может запретить замещение существующей резервной копии. По умолчанию используется параметр NoSkip.

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

?               NoFormat/Format. Перед созданием резервной копии магнитная лента (но не диск!) форматируется. При форматировании автоматически устанавливаются параметры Skip и Init.

?               Rewind/NoRewind. Указывает серверу автоматически перемотать ленту в начало (используется по умолчанию).

?               UnLoad/Load. Автоматически перематывает ленту в начало и выгружает ее. Этот параметр используется по умолчанию, пока в другой сессии не будет явно определен параметр Load.

?               Restart. Если резервное копирование с участием нескольких магнитных лент сорвалось до завершения операции, то параметр Restart поможет продолжить последовательность, начиная с точки сбоя, без необходимости возвращения к первой магнитной ленте. Использование этого параметра позволяет сэкономить время, однако после завершения операции резервирования не забудьте запустить проверку архива с помощью команды restore verifyonly (подробнее об этом — в следующем разделе).

Программная проверка резервной копии

При создании резервной копии в Managenet Studio у пользователя есть возможность проверить архив, чего не позволяет сделать команда backup. После завершения архивирования Management Studio вызывает команду restore verifyonly для выполнения верификации:

RESTORE VERIFYONLY

FROM DISK = ‘e:\Cha2Backup.bak’

В случае успешной проверки будет получен следующий результат:

The backup set is valid.

Проверка архива имеет несколько параметров, таких как Еj ect tape after backup. Большинство этих параметров предназначено только для магнитных лент (к тому же их название говорит само за себя).

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии