Резервное копирование и восстановление виртуализованного Microsoft Exchange с помощью Veeam Backup & Replication

[gotch]

Не могли бы вы уточнить какие вы предлагаете сценарии:
— для восстановления одного утраченного сервера в DAG
— для восстановления полностью утраченного кластера DAG

Дает ли продукт какие-либо преимущества по сравнению с традиционными сценариями восстановления?

[polarowl]

Для виртуализованных Exchange серверов, входящих в DAG, Veeam выполняет резервное копирование с помощью обычного задания backup job. Обязательно указать в настройках заданий для Exchange серверов, что надо создавать transactionally-consistent бэкапы с использованием VSS. Есть еще несколько полезных советов — в частности, как побороть VSS timeout и DAG cluster failover, который может иметь место при создании снапшота, и ряд других.О них в скором времени будет отдельный пост, но если информация нужна «ещё вчера», то можно почитать здесь (на англ.языке).
Соответственно, при наличии успешно созданного консистентного бэкапа доступны все возможности восстановления, реализованные в Veeam Backup & Replication: можно восстановить машину целиком, восстановить ее дисковые файлы, файлы гостевой системы, отдельные объекты из базы EDB, и т.д.

• При потере одного сервера — его можно восстановить целиком и синхронизировать с “живыми”, используя для этого стандартные процедуры рестора Exchange.
• При потере кластера DAG — можно восстановить все виртуальные машины из DAG целиком (при необходимости также и witness disk/FSW server) и опять же синхронизировать сервера стандартными средствами Exchange.

Что до сравнения с традиционными средствами, то можно сказать следующее: на сегодня мы умеем восстанавливать виртуальную машину из бэкапа либо объект из базы, не требуя восстановления машины. (В текущей версии не восстанавливаем базу целиком на сервер.) По сравнению с решениями, использующими агентов на ВМ, у Veeam восстановление отдельных объектов из базы значительно удобнее и быстрее.

[sysmetic]

Veeam Backup может восстановить как отдельный Exchange сервер, входящий в DAG, так и все сервера, которые в нее входят. Под «традиционными средствами», полагаю, вы понимаете саму технологию DAG? Если так, то отличия у Veeam следующие:

1. Прежде всего — это решения разного назначения. DAG — это обеспечение отказоустойчивости, а Veeam Backup — резервного копирования (по сути создания долговременного архива). Из этого вытекают последующие пункты списка...
2. DAG хорошо работает, если «погиб» целый сервер и можно быстро переключить пользователей на другой сервер, где есть копия данных. Если же нужно восстановить отдельное письмо или почтовый ящик, то хотя у DAG и есть свои инструменты гранулярного восстановления, но они ограничены по времени применения (например, в DAG Exchange 2010 отсроченные копии баз хранятся по умолчанию 24 часа).
3. Если отдельные письма ошибочно удалены пользователем, DAG разнесет это удаление по всем серверам, и уже через 24 часа письмо нельзя будет восстановить. Аналогично с вирусным повреждением писем. Бэкап же позволяет «заглянуть прошлое» на более значительное время, и получить из старой резервной копии оригинальный вариант письма.
4. Отсроченные базы DAG — это по сути логи инкрементальных изменений. Если их логическая структура хоть немного повредится, будет сложно восстановить целостную копию всей инфосторы Exchange. Полное восстановление сервера с использованием отсроченной базы будет длительным процессом, так как нужно будет «проиграть» все логи, чтобы применить все изменения — это общий недостаток инкрементальных схем.
5. Veeam Backup позволяет сохранять резервные копии в течение любого времени по любой схеме (полные, инкрементальные, дифференциальные, синтетические), что позволяет выбрать ту, которая оптимально подходит и по ресурсам и по скорости восстановления в случае сбоя. Кроме того, Veeam Backup позволяет хранить резервные копии off-site, используя при передаче встроенный WAN-дедупликатор. DAG тоже возможно настроить в off-site, но там сравнительно больше технических трудностей (нужно настроить DNS, в off-site должен быть домен контроллер, сетевая задержка должна не превышать определенного значения).

P.S. Прощу прощения, если не правильно понял вопрос, так как понять можно было по разному.

[TreyLav]

Если это не погрешность скриншотов — то шрифты ужасны.

[leschenko]

Это отключенное сглаживание в системе. Возможно скриншоты делались на сервере, где красивости не очень надо.

[reff]

Не красоты ради, а функционала для.
В поединке «резервное копирование» vs. «красотульки» победитель однозначен.