Резервное копирование баз данных Exchange 2013
Резервное копирование баз данных Exchange 2013 должно выполняться на регулярной основе, ведь от этого зависит сохранность ваших данных . Тем не менее, существуют некоторые тонкости в этом процессе, о чем я и постараюсь рассказать в статье.
Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — Exchange 2013 — Установка, настройка, администрирование.
Резервное копирование баз данных Exchange 2013
Базы данных Exchange 2013 достаточно устойчивы к сбоям различного характера. Тем не менее, как и любые важные бизнес-данные, они нуждаются в обязательном резервном копировании.
Хочу напомнить, что резервным копированием не являются следующие технологии:
- RAID — лишь уменьшает вероятность необратимой поломки дисковой подсистемы, но не защищает от неё полностью, а также никак не предохраняет от логического повреждения данных;
- Снимки виртуальной машины — в некоторой степени защищают лишь от логического повреждения данных, позволяя вернуться к сохраненному состоянию, но не защищают от выхода из строя самого сервера. Кроме того, в 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) и запускается по требованию.
Несмотря на очевидную важность бэкапов, необходимость в резервном копировании баз данных в некоторых случаях может отсутствовать:
- Когда ваш сервер Exchange 2013 является частью тестовой инфраструктуры;
- Когда используется DAG и количество копий каждой БД составляет не менее трех штук.
Во всех остальных случаях резервное копирование баз данных Exchange 2013 является острой необходимостью.
В первом случае резервное копирование все равно может быть полезным — ну не разворачивать же все с нуля, если тестовый сервер упадет. Второй вариант вполне приемлем и даже очень часто рекомендуется, в том числе и в серьезных источниках (читайте Microsoft Exchange Server 2013. Полное руководство), а также и в официальной документации 3 :
Настоятельно рекомендуется развернуть не менее трех неизолированных копий базы данных почтовых ящиков перед переходом с традиционных форм защиты базы данных, таких как RAID или традиционные архивы на основе VSS.
Вне зависимости от этого, вы должны прорабатывать алгоритмы восстановления в случае разных аварийных ситуаций.
Журналы транзакций
Неплохую живучесть БД Exchange 2013 обеспечивают журналы транзакций. Любые изменения данных отражаются сначала в них и уже только после этого попадают в реальную базу данных. Через журналы транзакций также происходит распространение изменений в другие базы данных, находящиеся в DAG. В общем смысле ведение журналов является скорее необходимостью, чем какой-то прихотью. Именно поэтому крайне не рекомендуется включение циклического ведения журналов для баз данных, не состоящих DAG.
Без регулярного выполнения резервного копирования вы столкнетесь с сильной нехваткой свободного места, которое будет заполняться журналами. Даже в тестовой среде объемы требуемого пространства будут очень велики:
На скриншоте изображены свойства папки, в которой хранится база данных почтовых ящиков пользователей вместе с журналами, которых в ней более 8000. Чтобы вы понимали масштаб: в БД всего 5 ящиков, в каждом из которых не более пары десятков писем без вложений.
Каким же образом избавиться от журналов? Рекомендую сразу оставить мысли про ручное удаление. В крайнем случае вы можете на некоторое время включить циклическое ведение журналов для нужных вам баз и сразу после усечения логов вернуть все обратно. Более приемлемый и правильный вариант — выполнить резервное копирование тома, на котором эти базы находятся. Это и обсудим в следующем разделе.
Резервное копирование
Стоит сразу оговориться, что далеко не все виды резервного копирования приведут к штатному усечению журналов транзакций. Наиболее простой вариант — выполнить резервное копирование томов, на которых находятся базы данных. Это усечет логи, а также обеспечит в будущем возможность восстановления на уровне приложения. В официальной документации доступна таблица 4 :
| Если… | То… |
|---|---|
| Создать резервные копии всех данных на сервере… | Резервное копирование с помощью службы VSS будет выполнено без усечения журналов транзакций для баз данных на сервере. |
| Выполнить выборочное резервное копирование, выбрав один или несколько томов… | Резервное копирование с помощью службы VSS будет выполнено с усечением журналов транзакций для баз данных в выбранных томах после завершения процесса. |
| Выполнить выборочное резервное копирование одной или нескольких отдельных папок… | Резервное копирование с помощью службы VSS будет выполнено с усечением журналов транзакций для баз данных. Однако восстановление резервных копий сведется к восстановлению отдельных файлов, так как параметр восстановления на уровне приложения будет недоступен. |
Обратите на неё особое внимание.
Чтобы выполнить полное резервное копирование с усечением журналов, лучше разделить бэкап системы и бэкап БД. То есть сначала вы делаете резервную копию системного диска, системных разделов и другой служебной информации, а уже потом, вместе с новой задачей резервного копирования, бэкапите полезную нагрузку — базы данных Exchange 2013.
Ниже я распишу подробно настройки однократной архивации тома с базами данных.
Резервное копирование без установленного компонента Система архивации данных Windows Server невозможно, а потому надо установить сначала его. Как только компонент установлен, можно приступать к созданию бэкапа 5 . Открываем оснастку wbadmin.msc и запускаем мастер однократной архивации:
Далее все шаги будут видны на скриншотах.
На первом окне нажимаем Далее и потом выбираем Настраиваемый тип конфигурации:
В выпадающем списке Добавить элементы отмечаем все диски, на которых у вас находятся базы данных Exchange 2013. Заходим в Дополнительные параметры — Параметры VSS и выбираем Полная архивация VSS:
На следующей странице выбор будет зависеть от вашей инфраструктуры. Для хранения бэкапа может использоваться Удаленная общая папка или же Локальные диски. Я выбрал локальный диск и пусть вас это не смущает, ведь я выполняю резервное копирование на тестовом сервере. Тем не менее, даже на тестовой инфраструктуре мой локальный диск F: виртуальной машины физически находится на другом жестком диске по отношению к самой виртуалке.
В вашем случае «локальным» диском может быть диск, подключенный по iSCSI, либо просто смонтированный сетевой диск.
На этапе подтверждения проверяем сводную информацию и нажимаем Архивировать.
Дожидаемся завершения процесса и идем смотреть что стало с логами:
Обратите внимание, что в папке осталось всего 37 файлов из 8 897 ранее — после резервного копирования произошло усечение журналов транзакций.
Ну и чтобы явно убедиться, что все прошло хорошо, выполним команду:
Using Windows Server Backup to back up and restore Exchange data
Microsoft’s preferred architecture for Exchange Server leverages a concept known as Exchange Native Data Protection. Exchange Native Data Protection relies on native Exchange features to protect your mailbox data, without the use of traditional backups. But if you want to create backups, Exchange includes a plug-in for Windows Server Backup (WSB) that enables you to create Exchange-aware Volume Shadow Copy Service (VSS)-based backups of Exchange data. To take Exchange-aware backups, you must have the WSB feature installed.
The plug-in, WSBExchange.exe, runs as a service named Microsoft Exchange Server Extension for Windows Server Backup (the short name for this service is WSBExchange). This service is automatically installed and configured for manual startup on all Mailbox servers. The plug-in enables WSB to create Exchange-aware VSS backups.
Before using WSB to back up Exchange data, we recommend that you familiarize yourself with the following features and options for the plug-in:
Backups taken with WSB occur at the volume level, and the only way to perform an application-level backup or restore is to select an entire volume. To back up a database and its log stream, you must back up the entire volume containing the database and logs, not just the individual folders. You can’t back up any data without backing up the entire volume containing the data.
The backup must be run locally on the server being backed up, and you can’t use the plug-in to take remote VSS backups. There is no remote administration of WSB or the plug-in. You can, however, use Remote Desktop Services or Terminal Services to remotely manage backups.
The backup can be created on a local drive or on a remote network share.
Only full backups should be taken. Log truncation will occur only after a successful completion of a VSS full backup of a volume or folders containing an Exchange database.
When restoring data, it’s possible to restore only Exchange data. This data can be restored to its original location or to an alternate location. If you restore the data to its original location, WSB and the plug-in automatically handle the recovery process, including dismounting any existing database and replaying logs into the restored database.
The restore process doesn’t support the Exchange recovery database (RDB). If you want to use an RDB, you must restore the data to an alternate location and then manually copy or move the restored data from that location into the RDB folder structure.
When restoring Exchange data, all backed up databases must be restored together. You can’t restore a single database.
Bare metal restores are supported when using WSB; however, the recommended recovery approach for Exchange servers is to recover the Exchange server and then restore the data. If you’re using a third-party backup application (e.g., non-Microsoft), then support for bare metal restores of Exchange may be available from your backup application vendor.
The following table describes the supportability of the backup and recovery options available for Exchange Server with WSB.
| If you. | Then. |
|---|---|
| Back up the full server. | A VSS copy backup will be performed, and the transaction logs for the databases on the server will not be truncated. |
| Perform a custom backup and select one or more volumes to back up. | A VSS full backup can be selected, allowing the transaction logs for the databases on the selected volumes to be truncated at the completion of a successful backup. |
| Perform a custom backup and select one or more folders to back up. | A VSS full backup can be selected and the log files will be truncated; however, restoration of the backup will be limited to file restore, as an Application level restore will not be available as an option. |
For detailed steps to back up Exchange using WSB, see Use Windows Server Backup to back up Exchange.
For detailed steps to restore data from a backup taken with WSB, see Use Windows Server Backup to restore a backup of Exchange.
Microsoft exchange extension windows server backup
This forum is closed. Thank you for your contributions.
Answered by:
Question
I am administering Microsoft Exchange Server 2007 on Windows Server 2008. All the latest updates for Windows Sever and Exchange 2007 and all stable drivers for hardware are installed. My concerns lay with lay with the behavior of «The Microsoft Exchange Server Extension for Windows Server Backup» service. Every time I check services panel it is in stopped state. When I start exactly after 5 minutes it stops. No error event is logged except:
The Microsoft Exchange Server Extension for Windows Server Backup service entered the stopped state.
I don’t have any other programs installed on the my Exchange Sever.
This happens since the Deployment of the Exchange Server back in 2010.
I would never think of it as an issue if I would not come across with mailbox corruption on my other Exchange Server. That’s why I want to make sure that everything is ok with this server.
Note I use Windows Server Backup to backup Exchange Server. That is why I need this service working.
Appreciate if anyone could help me on this!
Answers
Do you have Windows Server Backup Command line tool (Wbadmin) installed along with the normal Windows Server Backup?
WSBExchange will not work it is, please check and let me know.
This services helps Windows Backup to create an Exchange aware VSS copy.
All replies
TechNet Community Support
Thank you for your answer. I haven’t set u p Cluster Continuous Replication (CCR) on my Exchange yet. I will try to do it later. I need to research a little on this before doing as I am not expert on this field yet.
As for the issue, I have re-installed Windows Server Backup Features but this didn’t fix the problem. The Microsoft Exchange Server Extension for Windows Server Backup service enters to stopped state after exactly 5 minutes it has been started.
WSBExchange is set to manual startup, now this mean that it will run when the service is needed by backup.
Does your exchange Back up fails? If so please let me know the Utility you are using and the error code.
This service will stop if it remains idle. For more info on startup types of exhange services see:
However, if you want it to be running all the time, try changing the startup type to automatic but i am not sure if its required.
Hi Naveen Kannan
Thank you for your reply. I have done one back-up and closely monitored the WSBExchange service behaviour during this back-up process:
A: Before start of the backup process
1. Startup Type: Automatic
2. However it is in stopped state
3. Manual start results in after-5-minute stop
B: During backup
1. I manually started WSBExchange service at 7:00:00 and I checked event viewer to confirm the time
2. At 7:01:17 I initiated Windows Server Backup in Full Backup mode
3. At 7:05:00 WSBExchange service entered to stopped state when Backup was still going on
4. Backup ended at 7:50 but WSBExchange service never started again since it stopped at 7:05
My Exchange DB itself weights 50 GBs. Maybe it’s small but Windows Server Backup completed copying only 4 GBs of overall Exchange Server when WSBExchange service stopped.
I repeated it this experiment 1 more time and the result is almost the same with difference in time.
I suppose this «abnormal» behavior of WSBExchange service may result in low or bad quality backup when I use Windows Server Backup, right?
Of course when I use my backup for recovery I have 3 options
1. Files and Folders (not applicable in case of Exchange DB corruption)
Application recovery mode is disabled from the backups I have done! I have checked it on Win Srv Backup.
OK knowing that I am only left with Volume Recovery can this option guarantee successful recovery if we take into account that WSBExchange is out of order? (i.s: Will this have negative effect on Volume Recovery?)
I am not expert in Exchange Administration yet that’s why I really don’t know the answers for the above questions.
