- •Введение
- •Основная характеристика
- •История
- •Отличительные особенности версии sql Server 2005
- •Модели восстановления
- •Простая модель восстановления
- •Модель полного восстановления
- •Модель восстановления с неполным протоколированием
- •Выбор модели восстановления
- •Когда использовать простую модель восстановления
- •Когда использовать модель полного восстановления
- •Когда следует использовать модель восстановления с неполным протоколированием
- •Жесткий сбой системы (аварийный отказ аппаратуры).
- •Человеческие ошибки
- •Устройства, предназначенные для резервного копирования
- •Устройства хранения резервных копий
- •Устройства резервного копирования
- •Виды резервного копирования
- •Полное резервное копирование базы данных
- •Проверка настройки модели аварийного восстановления:
- •Разностное резервное копирование
- •Частичное резервное копирование
- •Резервное копирование журнала транзакций
- •Резервное копирование файлов и файловых групп
- •Расписание
- •Ограничения на операции резервного копирования в sql Server
- •Восстановление данных
- •Подготовка к восстановлению
- •Создаем информацию простого резервного копирования
- •Получаем общую информацию резервного копирования
- •Восстановление
- •Преимущества восстановления файлов или страниц
- •Стадии восстановления Стадия копирования данных
- •Стадия повтора (накат)
- •Точка восстановления
- •Согласованность повтора
- •Стадия отката и восстановление
- •Связь параметров recovery и norecovery со стадиями восстановления
- •Заключение
- •Список источников
-
Резервное копирование файлов и файловых групп
Если размер базы данных и требования по производительности делают полное резервное копирование базы данных нецелесообразным, можно создать резервную копию файла. Резервная копия файлов содержит данные одного или нескольких файлов или файловых групп.
Чтобы создать резервную копию файла или файловой группы, используйте инструкцию BACKUP DATABASE <файл_или_файловая_группа>. В этой инструкции должны быть указаны по меньшей мере следующие данные:
-
имя базы данных;
-
предложение FILE или FILEGROUP для каждого резервируемого файла или группы файлов;
-
устройство резервного копирования, на которое будет записываться полная резервная копия.
Базовая структура синтаксиса Transact-SQL для резервного копирования файлов:
BACKUP DATABASE database
{ FILE =logical_file_name | FILEGROUP =logical_filegroup_name } [ ,...f ]
TO backup_device [ ,...n ]
[ WITH with_options [ ,...o ] ] ;
-
Расписание
При выборе расписания резервного копирования необходимо учитывать:
-
размер базы данных. Если она очень большая, то стоит подумать о применении разностного резервного копирования;
-
режим восстановления;
-
интенсивность внесения изменений в базу данных. Обычно чем больше изменений вносится в нее, тем чаще нужно производить резервное копирование. Кроме того, при очень больших объемах изменяемых данных применение разностного резервного копирования может оказаться неэффективным;
-
насколько быстро в случае сбоя необходимо ввести базу данных в строй. Если она должна быть восстановлена быстро, то нет смысла использовать длинные цепочки резервных копий журналов транзакций.
В 9 из 10 случаев на отечественных предприятиях используется самое простое расписание резервного копирования: каждую ночь производится полное резервное копирование всей базы данных, и сразу после этого — резервное копирование журналов транзакций (для очистки). Если база данных не очень большая, то такой режим вполне можно считать оптимальным.
При этом обычно хранятся все резервные копии за последнюю неделю или две недели, а также резервные копии на начало месяца (чтобы можно было при необходимости восстановить базу данных и использовать ее для создания отчетов). Носители с ненужными резервными копиями используются повторно.
Корпорация Microsoft считает идеальным вариантом другое расписание резервного копирования (такой вывод можно сделать из официальных учебных курсов и сертификационных экзаменов):
-
раз в неделю — полное резервное копирование;
-
раз в сутки (каждую ночь) — разностное резервное копирование;
-
несколько раз в день — резервное копирование журналов транзакций.
Этот вариант наилучшим образом подходит для больших баз данных (десятки и сотни гигабайт), которые активно изменяются.
Можно использовать и другие варианты резервного копирования в зависимости от конкретных условий предприятия. Например, для не очень важных баз данных полное резервное копирование можно проводить раз в неделю и раз в день выполнять резервное копирование журналов транзакций.
В любом случае резервное копирование лучше производить тогда, когда нагрузка на сервер минимальна (обычно ночью).
Рекомендуется всегда одновременно с резервным копированием пользовательских баз данных производить резервное копирование баз данных master и msdb. По сравнению с пользовательскими базами данных места потребуется совсем немного, а восстанавливаться в случае каких-то проблем будет намного проще.
