Наконец мы добрались до процесса создания полных резервных копий баз данных. Нетрудно догадаться, что это едва ли не самый важный шаг. Если у системного администратора есть полные ночные резервные копии рабочих баз данных, то он может спать спокойно. В случае проблем, он по крайне мере может быстро откатиться на конец вчерашнего рабочего дня. Кроме того, зачастую такие резервные копии требуются даже если рабочая база данных в полном порядке с технической стороны дела. Бывает так, что были удалены важные данные и чтобы их увидеть пользователи просят восстановить резервную копию на вспомогательную или тестовую базу данных. Также такие резервные копии иногда просят восстановить в базу данных разработки.
Итак, приступим. Аналогично тому, как мы делали для предыдущих планов, выбираем из меню SSMS “Management (Управление)” –> “Maintenance Plans (Планы обслуживания)”, пункт контекстного меню “Maintenance Plan Wizard (Мастер планов обслуживания)”.
В следующем окне нам нужно будет дать имя нашему плану, например “MaintenancePlan-4”, которое будет отражать тот факт, что этот план должен будет выполняться четвёртым в нашей цепочке. Далее, как и ранее, даём описание (Description) плана, например “Full Backup”.
Здесь очень важно заметить почему мы делаем Full Backup после CheckDB, Reorganize Index и Update Statistics. Рассуждения здесь такие – нам нужна исправная оптимизированная копия базы данных, способная сходу заработать быстро. Если сначала сделать Full Backup, а потом выполнить Update Statistics, то в резервной копии окажутся устаревшие статистики. В этом случае, если придётся восстанавливать базу, оптимизатор запросов будет работать с неактуальными данными — возможна деградация производительности.
И ещё одна тонкость – делать регулярно Full Backup нужно не только для пользовательских, но и для системных баз данных. Однако выбирать в соответствующем окне опцию “All Databases (Все базы данных)”, не стоит, так как уж по крайней мере для тестовой базы данных нам резервная копия точно не нужна. Что касается расписания, то можно делать и то и то ежедневно, но лучшей практикой является и здесь разделение частоты обновления статистики для пользовательских и системных баз данных. Для первых действительно нужно это делать ежедневно. А для системных баз данных (кроме tempdb, для которой это делать не нужно вовсе) – достаточно раз в неделю.
Таким образом, также как и для MaintenancePlan-3, задаём расписания, назначив выполнение действия “Full Backup” на 3:15 ночи каждое воскресенье для системных баз данных и на 3:30 каждый день для пользовательских:
Комплексный план обслуживания, создающий полные резервные копии, как системных, так и пользовательских баз данных MS SQL Server
Понятно, что при выборе действия в окне “Select Maintenance Task (Выбор задач по обслуживанию)” ставим на этот раз птичку на флаге “Backup Database (Full)” или в русской версии: “Резервное копирование базы данных (полное)”.
На вкладке “Общее” для первого вложенного плана в поле “Базы данных” выбираем “Системные базы данных”, для опции “Создать резервную копию на” оставляем значение по умолчанию “Disk (Диск). Для второго вложенного плана выбираем конкретные пользовательские базы данных, для которых нужно будет регулярно делать полное резервное копирование. Обычно это только базы данных, с которыми происходит ежедневная работа.
Важно обратить внимание на то, что для этой задачи в основном окне имеются ещё две вкладки “Destination (Целевой объект)” и “Options (Параметры)”, которые крайне рекомендуется настроить тоже:
Важные опции процесса создания плана полного резервного копирования SSMS
В первой вкладке лучшей практикой является выбор “Create a backuo file for every database (Создать файл резервной копии каждой базы данных)” и при этом поставить птичку на флаге “Create a sub-directory for each database (Создавать вложенный каталог для каждой базы данных)”. При этом в поле Folder (Папка) желательно выбрать отличный от системного диск, который предлагается к выбору по умолчанию. Мы рекомендуем выбрать самый надёжный носитель (не обязательно быстрый) и создать в его корневой директории каталог MS SQL Backups.
Если всё сделать именно так, то больше никаких опций настраивать будет не нужно. Важно понимать, например, что в том случае, когда мы выбрали режим создания отдельного файла для резервной копии каждый раз при выполнении плана, опция “Backup set will expire (Срок действия резервного набора данных истекает)” бессмысленна:
Опции процесса создания плана обслуживания SSMS для полного резервного копирования баз данных, которые нет особого смысла менять
Также не имеет особого смысла и опция “Verify backup integrity (Проверять целостность резервной копии)” так как она не осуществляет реально проверки. С этой целью необходимо использовать опцию WITH CHECKSUM. Поскольку стандартная задача плана обслуживания этого не поддерживает, то лучшим решением будет написать собственный T-SQL скрипт внутри плана, но можно обойтись и без оного, ибо вам всё равно время от времени нужно будет восстанавливать резервную копию на тестовую базу данных, а это является самой лучшей практикой проверки правильности резервирования.
В целом, из этой последней вкладки Options (Параметры) полезной является “Perfome Checksome (Рассчитать контрольную сумму)”, но при условии, что мы перед осуществлением резервного копирования всегда делаем “DBCC CheckDB”, её выбор тоже особого смысла не имеет, хотя и не помешает, если у вас быстрый сервер. Оставляем здесь всё по умолчанию.
Стоит обратить внимание и на опцию “Copy only backup (Только резервное копирование)”. Она бессмысленна в обычных регулярных планах обслуживания. Но она крайне полезна для того, чтобы сделать свежую копию базы данных, не меняя основу для регулярных разностных резервные копий. Кроме того, в отличие от обычного резервного копирования журнала транзакций, режим “Copy only” не удаляет неактивные записи из лога, что важно для баз в модели восстановления FULL
