Бакапы в Exchange Server 2016


После выхода Exchange Server 2016 RTM интересно оценить, что в нём изменилось. В частности, относительно бакапов, или создания резервных копий.

Можно сразу сказать, что по сравнению с версией 2013 в версии 2016 RTM ничего не изменилось. Почти.

Если взять более ранние версии, то позитивные сдвиги есть и значительные.

Немного истории

Уже давно в Windows системах бакапы делаются на базе снапшотов, или VSS. В Exchange 2007 и 2010 репликация почтовых баз также построена на базе VSS. И кроме этого VSS используется не только в сервисе репликации Microsoft Exchange Replication service, но и в сервисе Microsoft Exchange Information Store service, который непосредственно управляет почтовыми базами. Такая архитектура привела к сложностям на практике при создании бакапов встроенными средствами Windows, что особенно было неудобно в DAG. Проблема была в том, что встроенный бакап мог делать копию только активной базы, копия пассивной базы получалась битой. Это означало, что на сервере все копии должны были быть активными, либо надо было на лету переключаться между двумя провайдерами VSS, которые были в Exchange: исправляем ключ реестра, рестартуем сервис, делаем бакап активных и пассивных баз, меняем обратно ключ, рестартуем сервис.

(Вместо встроенного бакапа можно было бы использовать DPM или продукты третьих фирм, которые используют собственные «нуки» в VSS. Если у вас несколько DAG, то затраты на такие продукты могут в какой-то степени считаться оправданными. При небольших масштабах использование встроенного бакапа более предпочтительно, но как уже сказано более неудобно. Но больших масштабах затраты на продукты резервного копирования могут также стать слишком огромными.)

В Exchange Server 2013 (и в 2016) два провайдера VSS были объединены в один – Microsoft Exchange Writer, который работает в сервисе репликации. В результате стало возможным делать бакапы всех баз на сервере как активных, так и пассивных без хитрых манипуляций.

Нужны ли бакапы?

Как известно, если Exchange развернут в конфигурации согласно рекомендациям продуктовой группы (PG) The Exchange 2016 Preferred Architecture, то бакапы не нужны. Совсем. И это универсально и выгодно как технически, так и финансово как для малых масштабов, так и для средних и в особенности для больших.

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

  1. Нет DAG, есть только одна копия почтовых баз – нельзя использовать циклическое логирование, бакапы делаются как можно чаще (раз в несколько часов, например)
  2. Есть DAG, но только две копии – циклическое логирование лучше не использовать, бакапы можно делать реже, чем при первом варианте (например, раз в сутки). Вторая копия базы обеспечивает непрерывность сервиса при поочередном обслуживании серверов или отказе одного из серверов.
  3. Есть DAG с тремя копиями, одна копия вынесена в другой ЦОД – циклическое логирование включено, бакапы делаются ещё реже (раз в неделю)
  4. Есть DAG с четырьмя копиями, два ЦОД-а – Exchange развернут по рекомендациям PG – бакапы не нужны

Теперь про 2016 и «почти».

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

Команда разработчиков обещает дополнительные нововведения в системе ввода-вывода Exchange, некоторые из них уже публично анонсированы и появятся уже в CU1 и CU2, некоторые пока остаются тайной. Вполне возможно, что эти новшества ещё более сузят круг применения бакапов в сценариях использования Exchange Server 2016.

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: