Резервное копирование баз данных Exchange 2013

Резервное копирование баз данных Exchange 2013 должно выполняться на регулярной основе, ведь от этого зависит сохранность ваших данных. Тем не менее, существуют некоторые тонкости в этом процессе, о чем я и постараюсь рассказать в статье.

---

Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики – Exchange 2013 — Установка, настройка, администрирование.

---

Резервное копирование баз данных Exchange 2013

Базы данных Exchange 2013 достаточно устойчивы к сбоям различного характера. Тем не менее, как и любые важные бизнес-данные, они нуждаются в обязательном резервном копировании.

Хочу напомнить, что резервным копированием не являются следующие технологии:

1. RAID – лишь уменьшает вероятность необратимой поломки дисковой подсистемы, но не защищает от неё полностью, а также никак не предохраняет от логического повреждения данных;
2. Снимки виртуальной машины – в некоторой степени защищают лишь от логического повреждения данных, позволяя вернуться к сохраненному состоянию, но не защищают от выхода из строя самого сервера. Кроме того, в Exchange 2013 использование снимков крайне не рекомендуется и официально не поддерживается (читайте Best Practices for Virtualizing and Managing Exchange 2013)

Для начала рассмотрим некоторые теоретические основы.

Теория

Exchange 2013 официально поддерживает резервное копирование лишь на основе VSS. Что для этого будет использоваться – Служба архивации Windows Server с поддержкой Exchange 2013, System Center Data Protection Manager или любое другое приложение, понимающее VSS – абсолютно непринципиально. Для выполнения резервного копирования и восстановления используется подключаемый модуль Exchange для VSS. Он работает в качестве службы (wsbexchange – Microsoft Exchange Server Extension for Windows Server Backup) и запускается по требованию.

Несмотря на очевидную важность бэкапов, необходимость в резервном копировании баз данных в некоторых случаях может отсутствовать:

1. Когда ваш сервер Exchange 2013 является частью тестовой инфраструктуры;
2. Когда используется DAG и количество копий каждой БД составляет не менее трех штук.

Во всех остальных случаях резервное копирование баз данных Exchange 2013 является острой необходимостью.

В первом случае резервное копирование все равно может быть полезным – ну не разворачивать же все с нуля, если тестовый сервер упадет. Второй вариант вполне приемлем и даже очень часто рекомендуется, в том числе и в серьезных источниках (читайте Microsoft Exchange Server 2013. Полное руководство), а также и в официальной документации ³:

Настоятельно рекомендуется развернуть не менее трех неизолированных копий базы данных почтовых ящиков перед переходом с традиционных форм защиты базы данных, таких как RAID или традиционные архивы на основе VSS.

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

Журналы транзакций

Неплохую живучесть БД Exchange 2013 обеспечивают журналы транзакций. Любые изменения данных отражаются сначала в них и уже только после этого попадают в реальную базу данных. Через журналы транзакций также происходит распространение изменений в другие базы данных, находящиеся в DAG. В общем смысле ведение журналов является скорее необходимостью, чем какой-то прихотью. Именно поэтому крайне не рекомендуется включение циклического ведения журналов для баз данных, не состоящих DAG.

Без регулярного выполнения резервного копирования вы столкнетесь с сильной нехваткой свободного места, которое будет заполняться журналами. Даже в тестовой среде объемы требуемого пространства будут очень велики:

На скриншоте изображены свойства папки, в которой хранится база данных почтовых ящиков пользователей вместе с журналами, которых в ней более 8000. Чтобы вы понимали масштаб: в БД всего 5 ящиков, в каждом из которых не более пары десятков писем без вложений.

Каким же образом избавиться от журналов? Рекомендую сразу оставить мысли про ручное удаление. В крайнем случае вы можете на некоторое время включить циклическое ведение журналов для нужных вам баз и сразу после усечения логов вернуть все обратно. Более приемлемый и правильный вариант – выполнить резервное копирование тома, на котором эти базы находятся. Это и обсудим в следующем разделе.

Резервное копирование

Стоит сразу оговориться, что далеко не все виды резервного копирования приведут к штатному усечению журналов транзакций. Наиболее простой вариант – выполнить резервное копирование томов, на которых находятся базы данных. Это усечет логи, а также обеспечит в будущем возможность восстановления на уровне приложения. В официальной документации доступна таблица ⁴:

Если…	То…
Создать резервные копии всех данных на сервере…	Резервное копирование с помощью службы VSS будет выполнено без усечения журналов транзакций для баз данных на сервере.
Выполнить выборочное резервное копирование, выбрав один или несколько томов…	Резервное копирование с помощью службы VSS будет выполнено с усечением журналов транзакций для баз данных в выбранных томах после завершения процесса.
Выполнить выборочное резервное копирование одной или нескольких отдельных папок…	Резервное копирование с помощью службы VSS будет выполнено с усечением журналов транзакций для баз данных. Однако восстановление резервных копий сведется к восстановлению отдельных файлов, так как параметр восстановления на уровне приложения будет недоступен.

Обратите на неё особое внимание.

Чтобы выполнить полное резервное копирование с усечением журналов, лучше разделить бэкап системы и бэкап БД. То есть сначала вы делаете резервную копию системного диска, системных разделов и другой служебной информации, а уже потом, вместе с новой задачей резервного копирования, бэкапите полезную нагрузку – базы данных Exchange 2013.

Ниже я распишу подробно настройки однократной архивации тома с базами данных.

Резервное копирование без установленного компонента Система архивации данных Windows Server невозможно, а потому надо установить сначала его. Как только компонент установлен, можно приступать к созданию бэкапа ⁵. Открываем оснастку wbadmin.msc и запускаем мастер однократной архивации:

Далее все шаги будут видны на скриншотах.

На первом окне нажимаем Далее и потом выбираем Настраиваемый тип конфигурации:

В выпадающем списке Добавить элементы отмечаем все диски, на которых у вас находятся базы данных Exchange 2013. Заходим в Дополнительные параметры – Параметры VSS и выбираем Полная архивация VSS:

На следующей странице выбор будет зависеть от вашей инфраструктуры. Для хранения бэкапа может использоваться Удаленная общая папка или же Локальные диски. Я выбрал локальный диск и пусть вас это не смущает, ведь я выполняю резервное копирование на тестовом сервере. Тем не менее, даже на тестовой инфраструктуре мой локальный диск F: виртуальной машины физически находится на другом жестком диске по отношению к самой виртуалке.

В вашем случае “локальным” диском может быть диск, подключенный по iSCSI, либо просто смонтированный сетевой диск.

На этапе подтверждения проверяем сводную информацию и нажимаем Архивировать.

Дожидаемся завершения процесса и идем смотреть что стало с логами:

Обратите внимание, что в папке осталось всего 37 файлов из 8 897 ранее – после резервного копирования произошло усечение журналов транзакций.

Ну и чтобы явно убедиться, что все прошло хорошо, выполним команду:

Которая покажет дату последнего успешного резервного копирования каждой базы данных на сервере:

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