В версии 8.0 Veeam Backup & Replication реализован широкий спектр возможностей для резервного копирования и восстановления виртуализованных SQL серверов и баз данных, включая популярные методы полного восстановления виртуальной машины, гранулярного восстановления на уровне файлов и восстановления баз с помощью инструмента Veeam Explorer для Microsoft SQL Server. О последнем из перечисленных и будет мой сегодняшний рассказ.
Разумеется, начинать надо «от печки» — то есть от понимания того, как возможности восстановления связаны с настройками резервного копирования и самого виртуализованного SQL Server.
Все знают, что Veeam создает резервную копию виртуальной машины на уровне образа – то есть в случае SQL Server будет сделан бэкап всего сервера целиком, включая все инстансы и базы на них. Для того чтобы бэкап получился непротиворечивым относительно транзакций (transactionally-consistent), при его создании следует задействовать обработку образа с учетом работы приложений (application-aware image processing). Более того, можно подготовить резервную копию сервера к тому, что впоследствии из нее будут восстанавливать конкретные базы данных на состояние в любой момент времени или даже на выбранную транзакцию.
Вот несколько факторов, которые нужно учитывать при планировании резервного копирования SQL Server для последующего восстановления баз данных:
Для того, чтобы обеспечить возможность восстановления базы данных на любой момент времени или на выбранную транзакцию, нам понадобится создать:
Посмотрим, как с этими задачами управляется Veeam Backup & Replication.
Итак, если нам нужно бэкапить логи (что даст нам возможность наиболее «прицельного» восстановления базы), то задание резервного копирования нашего SQL Server будет, по сути, включать в себя 2 взаимосвязанных задания:
Эта «связка» заданий работает так:
Согласно расписанию, Job Manager, работающий на сервере Veeam backup, запускает «родителя», который создает бэкап виртуальной машины с SQL Server и кладёт его в репозиторий.
Стартует сессия «ребенка»: с ее началом Veeam Backup & Replication устанавливает внутрь гостевой ОС нашего SQL сервера свой компонент под названием Veeam Log Shipper Service. Этот сервис будет работать в течение всей «детской» сессии и отвечать за обработку логов. Он, в частности, собирает информацию о том, журналы каких баз надлежит забэкапить в ходе сессии, и как именно можно передать данные в репозиторий (напрямую либо через log shipping server — назовем его «журнальный прокси»). По окончании «детской» сессии данный компонент останавливается и сносится с гостевой ОС; с началом новой сессии все повторяется (установка, сбор данных, остановка, деинсталляция).
Резервная копия журнала транзакций на гостевой ОС создается средствами самого SQL Server; он также выполняет транкейт логов на гесте. Получившиеся копии сохраняются в виде файлов .BAK во временной папке на гостевой файловой системе (по умолчанию это %allusersprofile%\Veeam\Backup).
Каждые 15 минут (периодичность по умолчанию) Job Manager выявляет, какие базы имеются на данном SQL Server, и соотносит получившийся перечень с данными о содержимом бэкапа виртуальной машины (берутся из базы Veeam Backup & Replication). Таким образом выясняется, для каких же баз есть журналы, которые должны быть «отвезены» в репозиторий и положены рядом с соответствующим бэкапом SQL сервера в ходе данного 15-минутного интервала.
Примечание: Если остались еще копии журналов, которые по какой-то причине не были «увезены» в репозиторий в ходе предыдущих интервалов, Veeam выявит их путем энумерации .BAK файлов во временной папке и пометит как «подлежащие перевозке».
Файлы .BAK передаются с геста на репозиторий (напрямую либо через «журнальный прокси»); сервис Veeam transport на стороне источника перед этим еще выполняет их компрессию согласно своим настройкам по умолчанию. На стороне репозитория компрессия выполняется согласно настройкам «родительского» задания (подробнее можно прочитать здесь – на русском языке).
После «перевозки» данных на репозиторий они удаляются из временной папки на виртуальной машине. Если что-то не удалось «перевезти» за время отведенного интервала, то эти файлы удалены не будут, а во время следующей 15-минутки Veeam повторит попытку.
Операции, которые выполняются в течение 15-минутного интервала (т.н. log backup interval), показаны на рисунке:
Совокупность таких интервалов (их продолжительность, кстати, можно менять) между двумя последовательными запусками «родительского» задания и представляет собой «детскую» сессию.
Если рисовать картинку, то это будет выглядеть вот так:
Поясню картинку словами. Допустим, задание «родитель» настроено на ежедневный запуск в 11 часов вечера, начиная с 5 мая. Тогда будет иметь место такая последовательность:
Примечание: Поскольку бэкап журналов требует наличия бэкапа соответствующей базы (читай, сервера), следует помнить, что журналы для каждой новой базы будут забэкаплены только после того, как успешно пройдет бэкап сервера с этой новой базой.
В репозиторий (рядом с бэкапом соответствующего сервера) сохраняются резервные копии журналов транзакций в виде файлов .VLB; по умолчанию путь к папке C:\backup\<SQL_server_VM_backup_job_name>. Туда же кладутся и метаданные цепочки резервных копий в виде файлов .VBM.
По умолчанию политика хранения файлов .VLB настроена на соответствие с политикой хранения бэкапов SQL сервера, чтобы всегда имелись логи, которые можно было бы «накатить» на выбранную точку восстановления сервера и получить нужное состояние базы. Естественно, что с удалением точки восстановления по истечении срока хранения соответствующие бэкапы логов также будут удалены.
Есть еще одна опция – хранить бэкапы .VLB указанное количество дней; она может пригодиться в том случае, если вы хотите сэкономить место и планируете хранить только самые свежие данные для восстановления на недавнее состояние. Однако следует убедиться, что политики хранения для бэкапа сервера и файлов .VLB настроены так, что точка восстановления сервера не будет удаляться раньше, чем соответствующий .VLB – иначе «накатить» логи будет не на что.
На шаге выбора объектов для включения в «родительское» задание надо учесть следующее:
На шаге Guest Processing при настройке процессинга гостевой ОС выбираем вот такие опции:
Вот, в общем-то, и всё. Нажимаем ОК, чтобы сохранить настройки, закрываем диалог, возвращаемся к мастеру задания и проходим его до финиша. При этом помним, что на шаге Schedule нашего «родительского» задания надо ОБЯЗАТЕЛЬНО выбрать галку Run the job automatically, иначе задание-«ребенок» не будет активировано.
В следующей части я расскажу о том, как можно реализовать выбранный сценарий восстановления и на какие моменты следует обратить внимание при подготовке и планировании этого процесса. А пока что можно почитать дополнительно:
Разумеется, начинать надо «от печки» — то есть от понимания того, как возможности восстановления связаны с настройками резервного копирования и самого виртуализованного 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).
- Какие SQL серверы надлежит бэкапить?
- Модель восстановления (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, то в настройках задания резервного копирования машинки нужно будет выбрать опцию Process transaction logs with this job:
Немного теории: разбираемся, как идут процессы
Для того, чтобы обеспечить возможность восстановления базы данных на любой момент времени или на выбранную транзакцию, нам понадобится создать:
- Резервную копию виртуальной машины с учетом работы приложения (то есть 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\<SQL_server_VM_backup_job_name>. Туда же кладутся и метаданные цепочки резервных копий в виде файлов .VBM.
По умолчанию политика хранения файлов .VLB настроена на соответствие с политикой хранения бэкапов SQL сервера, чтобы всегда имелись логи, которые можно было бы «накатить» на выбранную точку восстановления сервера и получить нужное состояние базы. Естественно, что с удалением точки восстановления по истечении срока хранения соответствующие бэкапы логов также будут удалены.
Есть еще одна опция – хранить бэкапы .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, иначе задание-«ребенок» не будет активировано.
А что дальше?
В следующей части я расскажу о том, как можно реализовать выбранный сценарий восстановления и на какие моменты следует обратить внимание при подготовке и планировании этого процесса. А пока что можно почитать дополнительно:
