Резервное копирование и восстановление баз данных виртуализованного Microsoft SQL Server
В версии 8.0 Veeam Backup & Replication реализован широкий спектр возможностей для резервного копирования и восстановления виртуализованных SQL серверов и баз данных, включая популярные методы полного восстановления виртуальной машины, гранулярного восстановления на уровне файлов и восстановления баз с помощью инструмента Veeam Explorer для Microsoft SQL Server. О последнем из перечисленных и будет мой сегодняшний рассказ.
Разумеется, начинать надо «от печки» — то есть от понимания того, как возможности восстановления связаны с настройками резервного копирования и самого виртуализованного SQL Server.
Все знают, что Veeam создает резервную копию виртуальной машины на уровне образа — то есть в случае SQL Server будет сделан бэкап всего сервера целиком, включая все инстансы и базы на них. Для того чтобы бэкап получился непротиворечивым относительно транзакций (transactionally-consistent), при его создании следует задействовать обработку образа с учетом работы приложений (application-aware image processing). Более того, можно подготовить резервную копию сервера к тому, что впоследствии из нее будут восстанавливать конкретные базы данных на состояние в любой момент времени или даже на выбранную транзакцию.
Планируем ресурсыВот несколько факторов, которые нужно учитывать при планировании резервного копирования SQL Server для последующего восстановления баз данных: Ресурсы инфраструктуры и требования политик резервного копирования и восстановления, а именно: Какие SQL серверы надлежит бэкапить? Veeam работает с Microsoft SQL Server 2005 SP4 и выше; поддерживаются все редакции. Для Microsoft SQL Server 2012 и выше поддерживаются AlwaysOn Availability Groups.
Каковы требуемые показатели RTO и RPO для баз данных? Периодичность бэкапов будет зависеть в том числе и от этих значений. Как правило, чем чаще делаются бэкапы, тем меньше времени потребуется на восстановление.
Насколько интенсивно приложения обращаются к базе? Наряду с показателем RTO, этот фактор нужно учитывать при настройке окна резервного копирования, расписания заданий бэкапа и расчете места для хранения бэкапов журналов транзакций (при необходимости их использования).
Достаточного ли размера репозиторий резервного копирования? Места должно хватать для резервных копий самого сервера и журналов транзакций. Полезно оценить, сколько места примерно потребуется для них. Это можно сделать, например, с помощью калькулятора, или использовать отчет VM Change Rate Estimation из пачки Infrastructure Assessment Reports (если у вас установлен Veeam ONE).
Модель восстановления (logging and recovery model) для требуемой базы данных. От нее зависит, какие опции обработки журналов транзакций можно будет использовать, и какие сценарии восстановления можно будет применять в дальнейшем: Если для базы указана модель Simple, то восстановить базу можно будет только на то состояние, в котором она пребывала в момент создания конкретной точки восстановления (бэкапа или реплики). В этом сценарии SQL Server будет автоматически выполнять транкейт логов.
Если модель иная (Full или Bulk-logged), то автоматический транкейт не будет происходить, и можно настроить нужные опции обработки логов.
Какой инструмент будет использоваться для резервного копирования и восстановления? Если для бэкапов виртуальной машины с SQL Server и журналов транзакций соответствующих баз будет задействован Veeam, то в настройках задания резервного копирования машинки нужно будет выбрать опцию Process transaction logs with this job: 
После этого станут доступны настройки процессинга журналов транзакций (об этом чуть позже).Примечание: Если эту опцию выбрать при настройке задания бэкапа машины с другим приложением (не SQL, а, скажем, Exchange Server), то она включит автоматический транкейт журналов транзакций для этого приложения. Подробнее о работе для Exchange см. статью на Хабре.
Если же вы планируете использовать Veeam только для создания бэкапа всей виртуальной машины, а журналы транзакций собираетесь передавать для обработки, скажем, стороннему приложению, то вам нужно оповестить об этом Veeam Backup & Replication — то есть указать, что цепочка бэкапов будет создаваться другим инструментом, а Veeam должен создавать свой бэкап с флагом COPY_ONLY (только в этом случае цепочка останется неизмененной). Это делается с помощью выбора опции Perform copy only (lets another application use logs): 
После этого настройки процессинга журналов транзакций будут «спрятаны» за ненадобностью; Veeam будет бэкапить данный SQL Server с использованием метода VSS_BS_COPY для создания снапшота; журналы транзакций трогаться не будут, так что администратору баз данных надо будет самому позаботиться о их дальнейшей судьбе.
Немного теории: разбираемся, как идут процессы Для того, чтобы обеспечить возможность восстановления базы данных на любой момент времени или на выбранную транзакцию, нам понадобится создать: Резервную копию виртуальной машины с учетом работы приложения (то есть SQL Server) Резервную копию журнала транзакций, который потом будет «накатываться» на имеющийся бэкап, чтобы привести базу к нужному состоянию Посмотрим, как с этими задачами управляется Veeam Backup & Replication.Итак, если нам нужно бэкапить логи (что даст нам возможность наиболее «прицельного» восстановления базы), то задание резервного копирования нашего SQL Server будет, по сути, включать в себя 2 взаимосвязанных задания:
Бэкап виртуальной машины с SQL Server — выполняется на уровне образа машины, фигурирует здесь и далее как «родитель», носит название, которые вы задали ему в UI (например, Test Job). Создается пользователем в консоли, запускается по расписанию либо вручную.
Бэкап журналов транзакций — фигурирует здесь и далее как «ребенок», носит имя «родителя» и суффикс SQL Backup (в нашем примере получится Test Job SQL Backup). Создается без участия пользователя, автоматически, компонентом Job Manager при выполнении обоих условий: существует хотя бы один «родитель», который будет запускаться по расписанию и создавать бэкап с учетом работы приложения (в настройках «родителя» выбрано Enable application-aware image processing)
включена опция бэкапа логов (также в настройках «родителя»)
Эта «связка» заданий работает так:
Шаги 1 и 2 Согласно расписанию, Job Manager, работающий на сервере Veeam backup, запускает «родителя», который создает бэкап виртуальной машины с SQL Server и кладёт его в репозиторий.Шаг 3 Стартует сессия «ребенка»: с ее началом Veeam Backup & Replication устанавливает внутрь гостевой ОС нашего SQL сервера свой компонент под названием Veeam Log Shipper Service. Этот сервис будет работать в течение всей «детской» сессии и отвечать за обработку логов. Он, в частности, собирает информацию о том, журналы каких баз надлежит забэкапить в ходе сессии, и как именно можно передать данные в репозиторий (напрямую либо через log shipping server — назовем его «журнальный прокси»). По окончании «детской» сессии данный компонент останавливается и сносится с гостевой ОС; с началом новой сессии все повторяется (установка, сбор данных, остановка, деинсталляция).Резервная копия журнала транзакций на гостевой ОС создается средствами самого SQL Server; он также выполняет транкейт логов на гесте. Получившиеся копии сохраняются в виде файлов .BAK во временной папке на гостевой файловой системе (по умолчанию это %allusersprofile%\Veeam\Backup).
Шаг 4 Каждые 15 минут (периодичность по умолчанию) Job Manager выявляет, какие базы имеются на данном SQL Server, и соотносит получившийся перечень с данными о содержимом бэкапа виртуальной машины (берутся из базы Veeam Backup & Replication). Таким образом выясняется, для каких же баз есть журналы, которые должны быть «отвезены» в репозиторий и положены рядом с соответствующим бэкапом SQL сервера в ходе данного 15-минутного интервала.Примечание: Если остались еще копии журналов, которые по какой-то причине не были «увезены» в репозиторий в ходе предыдущих интервалов, Veeam выявит их путем энумерации .BAK файлов во временной папке и пометит как «подлежащие перевозке».
Шаг 5 Файлы .BAK передаются с геста на репозиторий (напрямую либо через «журнальный прокси»); сервис Veeam transport на стороне источника перед этим еще выполняет их компрессию согласно своим настройкам по умолчанию. На стороне репозитория компрессия выполняется согласно настройкам «родительского» задания (подробнее можно прочитать здесь — на русском языке).После «перевозки» данных на репозиторий они удаляются из временной папки на виртуальной машине. Если что-то не удалось «перевезти» за время отведенного интервала, то эти файлы удалены не будут, а во время следующей 15-минутки Veeam повторит попытку.
Операции, которые выполняются в течение 15-минутного интервала (т.н. log backup interval), показаны на рисунке:
Совокупность таких интервалов (их продолжительность, кстати, можно менять) между двумя последовательными запусками «родительского» задания и представляет собой «детскую» сессию.
Начальная сессия стартует в момент, когда в настройках «родителя» было указано «Активировать расписание».
Задание «ребенок» продолжает работу в фоновом режиме между запусками «родителя», выполняя описанные выше операции. С запуском «родителя» текущая «детская» сессия завершается, и тут же стартует новая, вместе с «родителем» они проходят по шагам 1–5 (см. выше).
Завершается «детская» сессия непосредственно перед стартом «родителя», либо когда «родитель» деактивирован (через команду меню либо через деактивацию расписания).
Если рисовать картинку, то это будет выглядеть вот так: 
Пример Поясню картинку словами. Допустим, задание «родитель» настроено на ежедневный запуск в 11 часов вечера, начиная с 5 мая. Тогда будет иметь место такая последовательность: Самая первая «детская» сессия стартует в тот момент, когда для «родителя» было активировано расписание автоматического запуска (сам бэкап виртуальной машины еще не создан) — эта настройка была сделана в 7 часов вечера 5 мая. Задание-«ребенок» находится в состоянии Idle, ожидая, пока будет создан бэкап машины. В 11 вечера 5 мая запускается «родитель» и создает бэкап SQL сервера. Задание-«ребенок» переходит в состояние Working, и начинается последовательность 15-минутных интервалов. Если все бэкапы журналов были успешно «перевезены» в репозиторий до того, как подойдет время начала новой сессии, «ребенок» перейдет снова в состояние Idle и будет ожидать, пока время сессии не истечет. В 11 вечера 6 мая снова запускается «родитель», и стартует новая «детская» сессия. Примечание: Поскольку бэкап журналов требует наличия бэкапа соответствующей базы (читай, сервера), следует помнить, что журналы для каждой новой базы будут забэкаплены только после того, как успешно пройдет бэкап сервера с этой новой базой.
Что сохраняется в репозиторий?
В репозиторий (рядом с бэкапом соответствующего сервера) сохраняются резервные копии журналов транзакций в виде файлов .VLB; по умолчанию путь к папке C:\backup\
Есть еще одна опция — хранить бэкапы .VLB указанное количество дней; она может пригодиться в том случае, если вы хотите сэкономить место и планируете хранить только самые свежие данные для восстановления на недавнее состояние. Однако следует убедиться, что политики хранения для бэкапа сервера и файлов .VLB настроены так, что точка восстановления сервера не будет удаляться раньше, чем соответствующий .VLB — иначе «накатить» логи будет не на что.
Хватит теории, давайте уже практику! Настраиваем задание резервного копирования
Выбор объектов для задания
На шаге выбора объектов для включения в «родительское» задание надо учесть следующее: Базы данных, находящиеся на одном инстансе, будут обрабатываться последовательно.
Если вы хотите создавать бэкапы журналов транзакций для всех баз, за исключением одной или нескольких определенных, то для этих баз-исключений нужно указать модель восстановления simple.
Для SQL Server 2012 и выше Veeam поддерживает AlwaysOn Availability Groups (проверяем, что инстансы SQL находятся на нодах WSFC).
Настройка процессинга виртуальной машины с учетом работающего приложения (SQL сервера)
На шаге Guest Processing при настройке процессинга гостевой ОС выбираем вот такие опции: Зачекиваем галку Enable application-aware processing, чтобы процессинг виртуальной машины шёл с учетом работы приложений.
Идём в секцию Guest OS credentials и указываем учетную запись, под которой хотим выполнять действия на гостевой ОС (в т.ч. это бэкап логов с гостевой ОС на репозиторий и транкейт логов). Для этой учетной записи понадобятся следующие права: Для бэкапа — фиксированная серверная роль sysadmin на обрабатываемом SQL Server. Для транкейта — если у вас SQL Server 2012 или SQL Server 2014, то минимум роль db_backupoperator для нужной базы, либо опять-таки серверная роль sysadmin. Важное примечание: Начиная с Veeam Backup & Replication 8.0 Update 2 (билд 8.0.0.2021), в случае неудачной попытки транкейта под указанной учетной записью будет выполнена еще одна попытка, под учетной записю NT AUTHORITY\SYSTEM.Поэтому для SQL Server 2012 или SQL Server 2014 следует убедиться, что у этой учетной записи достаточно прав (подробнее см. http://www.veeam.com/kb1746).Что же до SQL Server 2005, 2008 и 2008 R2, то для них настройки по умолчанию обеспечивают для local SYSTEM нужные права (однако всегда есть вероятность, что кто-то мог их поменять — на такой случай рекомендуем всё еще разок перепроверить).
Затем жмём кнопку Application, в представленном списке выбираем нужный нам SQL Server и нажимаем кнопку Edit, после чего откроется диалог с настройками процессинга гостевой ОС.
Идём на вкладку General, находим там секцию Applications и выбираем опцию Require successful processing (recommended) — при такой настройке Veeam прекратит процесс бэкапа при любой ошибке, полученной от VSS в ходе «заморозки» нашего приложения. Таким образом мы нацеливаемся на создание резервной копии, непротиворечивой относительно транзакций (transactionally-consistent backup).
Далее идем в секцию Transaction logs и выбираем там опцию Process transaction logs with this job — как рассказывалось выше, это означает, что и бэкап виртуальной машины, и бэкап логов будут выполняться с помощью Veeam. После этого станет доступен таб SQL, где нужно выбрать, что вы хотите делать с логами (то бишь журналами транзакций). Доступны вот такие варианты: Truncate logs (prevent logs from growing forever) — хотим транкейтить логи. Не забываем, что у учетной записи, которая будет использована для работы с гостевой ОС, должны быть соответствующие права. В таком варианте Veeam дождется окончания бэкапа виртуальной машины и затем даст сигнал к транкейту логов (который выполнится с помощью VSS). Данная опция позволит вам восстановить базу только на выбранную точку восстановления (более «прицельное» восстановление не будет возможно). Do not truncate logs (requires simple recovery model) — хотим оставить логи на SQL сервере как есть, т.е. чтобы Veeam ничего с ними не делал (ни бэкап, ни транкейт). В таком варианте что-то делать с ними придется вашему администратору баз данных (иначе логи могут разрастись и занять кучу места, вот почему тут написано — «используйте модель simple в случае выбора этой опции»). Данная опция также позволит вам восстановиться только на выбранную точку. Backup logs periodically — хотим сохранять бэкапы логов в репозиторий рядом с бэкапом самого SQL сервера. Данная опция позволяет использовать любой сценарий восстановления.Выбираем, с какой периодичностью хотим «перевозить» логи на репозиторий (по умолчанию это те самые каждые 15 минут); устанавливаем политику хранения (рекомендуется According to the corresponding image-level backup). Ну и в завершение указываем «журнальный прокси», через который данные «поедут» в репозиторий.
Для переноса файлов в репозиторий с гостевой ОС поддерживаются 2 типа транспорта: Непосредственно с гостевой ОС на репозиторий — это оптимальный метод, поскольку не требует дополнительных ресурсов и по минимуму нагружает гостевую систему. Если непосредственное соединение установить невозможно, то используем log shipping server, или «журнальный прокси» — это может быть любой Windows-сервер, добавленный в консоль Veeam Backup & Replication. Можно указать, что выбор «журнального прокси» должен происходить автоматически, или самим выбрать подходящие серверы из списка. Veeam будет автоматически назначать на роль прокси один из серверов, ориентируясь на 2 критерия — возможные способы передачи данных и доступность по сети. Разумно также иметь более одного прокси для этой цели (на случай сбоя). Подробнее о «журнальных прокси» см. здесь. Что касается расписания, то «родительское» задание рекомендуется запускать в часы минимальной загрузки продакшена. Задание-«ребенок» (т.е. бэкап логов) по умолчанию будет пытаться «перевезти» логи на репозиторий каждые 15 минут — этот интервал можно поменять. Разумеется, при этом надо брать в расчет реальное время, за которое осуществляется передача файлов на репозиторий (т.е. не надо ставить интервал в 5 минут, если на самом деле процесс занимает все 15). Вот, в общем-то, и всё. Нажимаем ОК, чтобы сохранить настройки, закрываем диалог, возвращаемся к мастеру задания и проходим его до финиша. При этом помним, что на шаге Schedule нашего «родительского» задания надо ОБЯЗАТЕЛЬНО выбрать галку Run the job automatically, иначе задание-«ребенок» не будет активировано.А что дальше? В следующей части я расскажу о том, как можно реализовать выбранный сценарий восстановления и на какие моменты следует обратить внимание при подготовке и планировании этого процесса. А пока что можно почитать дополнительно:
