Настройка регулярного резервного копирования БД MS SQL Server. Создание автоматического бэкапа SQL-базы на сервере SQL Express Edition Резервное копирование sql server agent

«Кто владеет информацией - тот владеет миром» - Майер Амшель Ротшильд

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


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

Разберем на простейшем примере: необходимо настроить резервное копирование базы данных на отдельный диск.

Решение:

  1. Открываем Microsoft SQL Server Management Studio . В навигационном меню справа открываем вкладку "Управление" . Там видим вкладку "Планы обслуживания" . Нажимаем правой кнопкой мыши -> "Создать план обслуживания" и даем имя нашему плану (Рис.1):

Рис.1 Создание нового плана обслуживания.

2. На панели элементов добавляем задачу "Резервное копирование базы данных" (Рис.2):

Рис.2 Добавление задачи "Резервное копирование базы данных".

3. На созданной задаче нажимаем правой кнопкой мыши -> "Изменить" (Рис.3):

4. В окне свойствах задачи выбираем тип резервной копии (в моем случае полный), выбираем нужную базу данных (у меня ka_cons), каталог для бэкапов, возможность проверки резервных копий на целостность и варианты сжатия оных (Рис.4-6):


Рис.4 Тип бэкапа - полный.

Рис.5 Выбор базы данных для бэкапа.

Рис.6 Определение каталога для бэкапов, проверки целостности и степени сжатия.

5. На панели настройки плана обслуживания справа. нажимаем на кнопку "Расписание" (Рис.7):

6. Настраиваем нужное нам расписание и нажимаем "Ок" (Рис.8):

Рис.8 Настройка расписания резервного копирования.

7. Сохраняем наш план обслуживания (Рис.9):

Рис.9 Сохранение плана обслуживания.

Полное резервное копирование базы данных по расписанию настроено.

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

Для этого можно использовать либо встроенный в SQL Server планировщик заданий - «SQL Server Agent» (в бесплатную версию не входит), либо стандартный «Планировщик Windows» в сочетании с утилитой SQLCMD.EXE, которая позволяет выполнять запросы к SQL Server из командной строки. В планировщике необходимо создать как минимум семь заданий (по одному на каждый день недели), каждое из которых будет (раз в неделю) заменять один из семи файлов, содержащих соответствующую резервную копию базы данных.

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

С помощью «Планировщика Windows» (для бесплатной версии)

Чтобы создать задание в «Планировщике Windows» надо:

Запустить программу «Блокнот» (Пуск->Все программы->Стандартные->Блокнот) и ввести следующие две строки, после чего сохранить их в виде командного файла (*.BAT):

SQLCMD -S (local) -E -Q "BACKUP DATABASE AltaSVHDb TO DISK = "D:\BACKUP\ AltaSVHDb_monday.bak" WITH INIT, NOFORMAT, SKIP, NOUNLOAD"
XCOPY D:\BACKUP\ AltaSVHDb_monday.bak \\BACKUP_SERVER\Folder\*.* /Y

где «(local)» - имя сервера (в случае установки именованного экземпляра SQL Server надо указать имя полностью: «ИМЯ_КОМПА\SQLEXPRESS»), «AltaSVHDb» - имя базы данных, «D:\BACKUP\ AltaSVHDb_monday.bak» - имя файла для создания в нем резервной копии (будет различаться по дням недели), «BACKUP_SERVER» - имя компьютера, на который будет выполняться дополнительное копирование, «Folder» - папка на этом компьютере (к ней должен быть предоставлен общий доступ).

Запустить мастер планирования заданий (Панель управления->Назначенные задания->Добавить задание) и нажать кнопку «Далее»:

Нажать кнопку «Обзор» и указать путь к командному файлу (*.BAT), созданному на шаге a):

Указать имя для задания, выбрать вариант запуска «еженедельно» и нажать кнопку «Далее»:

Поставить галочку возле нужного дня недели, а в поле «Время начала» указать время, когда должен запускаться процесс резервного копирования (обычно это делается ночью), затем нажать кнопку «Далее»:

Ввести имя пользователя и пароль (дважды) учетной записи ОС, от имени которой будет выполняться задание, и нажать кнопку «Далее»:

Внимание! Чтобы задание успешно выполнялось необходимо предоставить указанной здесь учетной записи (домена или локального компьютера) права записи в вышеупомянутую папку «\\BACKUP_SERVER\Folder» , а также настроить доступ к самому SQL Server.

Нажать кнопку «Готово»

Примечание . Чтобы проверить работоспособность созданного задания, необходимо в списке заданий (Панель управления->Назначенные задания) нажать правой кнопкой мыши на интересующем задании и в контекстном меню выбрать пункт «Выполнить», затем убедиться, что файл резервной копии БД успешно создался по тем путям, которые были указаны на шаге a).

С помощью «SQL Server Agent» (в бесплатную версию не входит)

Чтобы создать задание в «SQL Server Agent» надо:

Запустить утилиту SQL Server Management Studio и подключиться к серверу под учетной записью администратора.

В левой части окна нажать правой кнопкой мыши на разделе «Объекты сервера/Устройства резервного копирования» и в контекстном меню выбрать пункт «Создать устройство резервного копирования»:

В поле «Имя устройства» ввести имя, которое будет ассоциироваться с файлом резервной копии БД, при необходимости изменить путь в поле «Файл» и нажать «ОК»:

В левой части окна нажать правой кнопкой мыши на разделе «Агент SQL Server/Задания» и в контекстном меню выбрать пункт «Создать задание»:

В поле «Имя» ввести имя задания:

На странице «Шаги» нажать кнопку «Создать»:

В появившемся окне ввести имя в поле «Имя шага», проверить, что в поле «Тип» выбрано «Сценарий Transact-SQL (T-SQL)», а в поле «Команда» ввести строку:

BACKUP DATABASE AltaSVHDb TO AltaSVHDb_monday WITH INIT, NOFORMAT, SKIP, NOUNLOAD

где «AltaSVHDb» - имя базы данных, «AltaSVHDb_monday» - имя устройства резервного копирования, созданного на шаге c) (будет различаться по дням недели):

В предыдущем окне нажать кнопку «ОК», в результате на странице «Шаги» должна появиться строка:

Чтобы файл резервной копии БД сразу копировался на другой компьютер в сети необходимо повторить пункты f) - h), в окне «Создание шага задания» выбрав в поле «Тип» значение «Операционная система (CmdExec)», а в поле «Команда» указав строку:

XCOPY D:\MSSQL\BACKUP\AltaSVHDb_monday.bak \\BACKUP_SERVER\Folder\*.* /Y

где «D:\MSSQL\BACKUP\AltaSVHDb_monday.bak» - путь, указанный на шаге c) (будет различаться по дням недели), «BACKUP_SERVER» - имя компьютера, на который будет выполняться копирование, «Folder» - папка на этом компьютере (к ней должен быть предоставлен общий доступ):

Примечание . Чтобы копирование файла успешно выполнялось необходимо запускать «SQL Server Agent» под учетной записью домена Windows, для которой предоставлены права записи в вышеупомянутую папку (см. также «SQL2005_installation.doc» или «SQL2008_installation.doc»), а также настроен доступ к самому SQL Server (см. раздел «Настройка прав доступа к БД», включить эту учетную запись надо в роль «sysadmin» на странице «Серверные роли», а на страницах «Сопоставление пользователей» и «Защищаемые объекты» ничего не делать).

На странице «Расписания» нажать кнопку «Создать»:

Ввести имя в поле «Имя», проверить, что в поле «Тип расписания» выбрано значение «Повторяющееся задание», а в поле «Выполняется» - «Еженедельно». Поставить галочку возле нужного дня недели (остальные снять), а в поле «Однократное задание» указать время, когда должен запускаться процесс резервного копирования (обычно это делается ночью):

В предыдущем окне нажать кнопку «ОК», в результате на странице «Расписания» должна появиться строка:

Нажать кнопку «ОК».

Примечание . Чтобы проверить работоспособность созданного задания, необходимо в разделе «Агент SQL Server/Задания» нажать правой кнопкой мыши на интересующем задании и в контекстном меню выбрать пункт «Запустить задание на шаге», в появившемся окне выбрать первый шаг данного задания и нажать «ОК». Далее появится окно отображающее ход выполнения задания. Если выполнение задания закончится с ошибкой, то подробное описание ошибки можно увидеть вызвав пункт «Просмотр журнала» того же контекстного меню.

Восстановим базу «Test _Recovery » в состояние «t 4 ».

Приступим к восстановление базы данных из полной резервной копии «Full2_Test_Recovery.bak» используя « SQL Server Management Studio ». Щелкаем правой кнопкой мыши по базе « Test _ Recovery », в появившемся меню выбираем « Tasks », далее « Restore », потом « Database ».

В появившемся окне « Restore Database » в разделе « Sourse » выбираем « Device ». Далее « Add », прописываем путь «\\ vniz - tst - bkp 01. test . local \ Backup _ SQL \ Full 2_ Test _ Recovery . bak », нажимаем « Ok ». В разделе «Destination» выбираем Database «Test Recovery»

Нажимаем «Ok»

База успешно восстановится.

Рассмотрим восстановление базы данных используя Transact-SQL.

Щелкаем правой кнопкой мыши по базе «Test_Recovery», в появившемся меню выбираем «New Query»:

В появившемся окне вводим:

USE master

RESTORE DATABASE Test_Recovery

FROM DISK = "\\vniz-tst-bkp01.test.local\Backup_SQL\Full2_Test_Recovery.bak"

WITH REPLACE

База успешно восстановится.

В этом примере мы использовали параметр «REPLACE»:

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

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

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

Данная статья посвящена решениям для восстановления MS SQL. Постараемся рассмотреть основные моменты и важные детали, которые необходимо учесть, при планировании и выборе решения для восстановления базы данных MS SQL.

В рамках планирования аварийного восстановления MS SQL особый интерес представляют два параметра: допустимое время восстановления (recovery time objective - RTO) и допустимая точка восстановления (recovery point objective - RPO).

RPO иными словами, это период времени с момента последнего резервного копирования до момента инцидента, за который будет потерян не критичный объём данных (информации). RTO - это допустимое время, за которое необходимо восстановить работоспособность сервиса/системы с момента инцидента. Оба параметра имеют переменное значение и зависят от требований к той или иной системе. Поэтому для выполнения, установленных RPO и RTO необходимо иметь соответствующий план резервного копирования. На примере, проведём анализ возможных аварийных инцидентов и попробуем выделить точки отказа нашего SQL сервера и способы их решения:

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

HIGH AVAILABILITY MS SQL

При высоких требованиях к RPO и RTO (секунды/минуты) единственным решением для обеспечения отказоустойчивости MS SQL является организация технологии высокой доступности сервера (High Availability):

  • Встроенными средствами MS SQL и ОС Windows Server мы можем достичь высокой доступности (High Availability) за счет реализации отказоустойчивого кластера Windows Server Failover Cluster (WSFC) в том числе и с применением технологии AlwaysOn. Отказоустойчивый кластер состоит как минимум из двух узлов/серверов. При сбое активного сервера, происходит аварийное переключение на другой доступный сервер, он становится активным. При этом все службы, которые размещались на сервере автоматически или вручную переносятся на другой доступный узел.
  • В случаи, с виртуальной машиной MS SQL высокую доступность можно обеспечить c помощь средств виртуализации VMware HA-cluster или Hyper-V High Availability. В этом случае при выходе из строя физического сервера, позволяет автоматически запустить виртуальную машину на другом сервере кластера.

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

Преимущества High Availability MS SQL:

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

Недостатки High Availability MS SQL:

  • реализации требует дополнительной инфраструктуры и ресурсов
  • высокая стоимость решения по лицензиям и оборудованию
  • более сложное и высоквалифицированное обслуживание

BACKUP MS SQL

В случаях, когда требования к RTO и RPO не высокие и потребность в High Availability (кластеризации) отсутствует, для обеспечения отказоустойчивости баз данных MS SQL на физическом или виртуальном сервере необходимым условием является наличие резервной копии. Для этого можно задействовать встроенные функции SQL Server или использовать отдельные специализированные системы, поддерживающие различные способы резервного копирования MS SQL, например:

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

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

Регламент backup MS SQL

  • Резервные копии должны находиться на разных физических носителях с исходными файлами базы данных
  • Используйте тестовый сервер (песочница) для проверки процедуры восстановления резервных копий
  • Выполняйте ежедневное
  • Делайте как можно чаще. Они занимают гораздо меньший объем в хранилище и еще больше сокращают риск потери данных
  • Как можно чаще выполняйте резервное копирование журналов транзакций. Журналы транзакций содержат все последние действия, произошедшие в базе данных. Журналы можно использовать для восстановления базы данных на определенный момент времени, и это является самым большим преимуществом. Резервные копии журнала транзакций могут выполняться во время работы системы. Если частота новых данных, создаваемых в вашей базе данных, очень высока, то можно делать резервные копии журнала транзакций каждые 10 минут, в то время как для других баз данных, которые менее активны, такое резервное копирование может выполняться каждые 30 или 60 минут
  • Делайте резервное копирование системных баз данных MS SQL: server, master , model и msdb . Эти базы данных абсолютно необходимы, так как содержат конфигурацию системы, а также информацию о задании SQL Server, которую необходимо будет восстановить в случае полного восстановления системы

НАСТРОЙКА РЕЗЕРВНОГО КОПИРОВАНИЯ MS SQL С ПОМОЩЬЮ BACKUP EXEC

Backup Exec предлагает три метода резервного копирования MS SQL: Full, Differential и Full Copy-only. Метод Full выполняет полное резервное копирование всей базы данных, а Differential выполняет резервное копирование только измененых блоков в базе данных с момента последнего полного резервного копирования. Метод Full Copy-only идентичен полному резервному копированию, но только он не влияет на последующие задания дифференциального резервного копирования.

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

Затем, в настройках параметров (опции) выбрать тип задания (сначала настроить Full потом Differential backup).



В Backup Exec есть очень важная и полезная функция «Проверка целостности базы до и после выполнения резервного копирования» (Consistency check before/after backup), имеется на выбор четыре варианта:


Для настройки differential backup необходимо (аналогично job full backup) сначала добавить новое задание Job Differential, а затем на вкладке Microsoft SQL выбрать один из методов резервного копирования.


В данном списке в первую очередь интересует «Differential - Backup up database changes since the last full» (создание дифференциальной резервной копии на основании полной). Так же возможен вариант создания дифференциальной резервной копии (на уровне блоков) с последующей конвертацией в виртуальную машину «Differential (block-level) - Backup up database changes since the last full – use with convert to virtual machine job» .

Еще одним важным параметром является «Log - Back up and truncate transaction log» для резервного копирования журнала транзакций MS SQL.

Мы рассмотрели основные моменты резервного копирования MS SQL. Обращаем внимание, что резервное копирование является частью общего плана аварийного восстановления (DRP), поэтому, перед планированием резервного копирования, необходимо провести полный анализ систем и инфраструктуры, для обеспечения RPO и RTO. А если есть возможность выполнить планирование DRP при разработке системы, это поможет исключить многие проблемы и, возможно, удешевит эксплуатацию системы.

Используемая в статье информация взята из официальных источников.

sqlcmd -S DECLSERVER\SQLGTD -E -Q «declare @s varchar(255) set @s=’E:\backup\GTD_’ + convert(varchar(1), datepart(dw, getdate())) + ‘.bak’ backup database GTD to disk = @s with init, noformat, skip, nounload»

sqlcmd позволяет вводить инструкции Transact-SQL, системные процедуры и файлы скриптов из командной строки в редактор запросов в режиме SQLCMD,

  • -S - задает имя сервера, server[\instance_name] ;
  • DECLSERVER\SQLGTD - имя сервера/имя экземпляра, на котором крутится база;
  • -E - использует для соединения с SQL server вместо имени пользователя и пароля доверительное соединение;
  • -Q «cmdlinequery « - при запуске программы sqlcmd выполняет запрос, но выход из программы по завершении его выполнения не производится. Может быть выполнено несколько запросов, разделенных точкой с запятой. Заключайте запрос в кавычки, как показано выше;
  • declare - объявляем переменную s ,имя переменной всегда начинается с @, поэтому @s . В нашем случае @s - это папка (диск) хранения бэкапов;
  • varchar(n) - задает тип переменной @s как строковый с длинной строки n, в примере 255 символов;
  • set - задает значение переменной @s ,в примере это папка backup на диске E (E:\backup\ ), далее задается имя бэкап файла, где набор функций convert(varchar(1), datepart(dw, getdate())) возвращает в текстовом формате с длиной в 1 символ текущий день недели (понедельник – 1 , вторник – 2 , и т.д.) и добавляется расширение bak . На выходе получим файл с именем GTD_НомерДняНедели.bak ;
  • backup - создает бэкап;
  • database - указывает на создание бэкапа всей базы;
  • GTD - в нашем примере имя базы на SQL-сервере;
  • to disk - указывает на тип устройства резервного хранения, файл жесткого диска, и указана переменная @s , которой присвоено путь и имя создаваемого файла;
  • with init, noformat, skip, nounload - указывает на то, что необходимо произвести перезапись данных по кругу с переопределением заголовков, что позволит нам иметь 7 файлов бэкапа на каждый день недели, перезаписываемые по кругу.

При необходимости можно использовать и другие функции, например сжатие, см. справку по запросам и функциям Transact-SQL.

Шаг 2. Меняем расширение текстового файла на.cmd

В итоге получаем файл backupGTD.cmd . Запускать созданный командный файл необходимо с той машины, где установлена БД MS SQL.

Шаг 3. Автоматизируем данный процесс

Рассмотрим данный шаг на примере MS Windows Server 2008: Диспетчер сервера -> Конфигурация -> Планировщик заданий -> Библиотека планировщика заданий.

Похожие публикации