Конец традиционным резервным копиям благодаря встроенной функциональности в Exchange 2010 (Часть 3)

Во 2 части этого цикла статей мы вкратце рассмотрели функцию litigation hold, а затем перешли к пошаговому рассмотрению того, как легко восстанавливать почтовые объекты для пользователя, используя функцию почтового поиска в Exchange 2010.

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

Отсроченные копии баз данных

Функция аварийной непрерывной репликации (Standby Continuous Replication – SCR), которая была представлена в Exchange 2007 SP1, давала нам возможность замены одной или нескольких баз данных отдельного сервера почтовых ящиков, кластера CCR, или кластера SCC на целевом отдельном сервере почтовых ящиков или аварийном кластере (CCR или SCC кластере, где была установлена только роль пассивных кластерных почтовых ящиков). SCR могла использоваться для репликации групп хранения локально в центре данных, а также удаленно на серверы, расположенные в резервном или аварийном центре данных.

Помимо возможности репликации данных во многие цели для каждой группы хранения, SCR также представила концепцию времени запаздывания воспроизведения и времени запаздывания усечения. Благодаря времени запаздывания воспроизведения можно было настраивать службу репликации Microsoft Exchange Replication на ожидание в течение определенного времени, прежде чем лог файлы, которые были скопированы с SCR источника в SCR цель(и), воспроизводились. Значением по умолчанию для этого параметра было 24 часа и его можно было настраивать с максимальным значением до 7 дней (если было установлено значение 0 секунд, то было время запаздывания для 50 лог файлов, поэтому перезаполнение не требовалось при возникновении ситуации обхода отказа с потерями). Суть времени запаздывания воспроизведения заключалась в том, что можно было иметь базу данных из определенного момента в прошлом, которую можно было использовать для восстановления, если копия/копии активной базы данных в сервере-источнике SCR были подвержены логическому повреждению. Таким образом можно было предотвратить репликацию до того, как логическое повреждение реплицируется на целевой сервер SCR, а, следовательно, предотвратить потерю данных.

Время запаздывания усечения могло использоваться для указания того, как долго должна служба репликации Microsoft Exchange Replication ждать до усечения (удаления) лог файлов, которые были скопированы на целевой сервер SCR и воспроизвелись в копии базы данных. Максимально допустимым значением для времени запаздывания усечения было 7 дней, а минимальным 0 секунд, при котором задержка усечения полностью убиралась. С помощью времени запаздывания усечения можно было восстанавливаться после сбоев, которые влияли на лог файлы на серверах-источниках SCR.

Группы Exchange 2010 Database Availability Groups (DAGs) также поддерживают время запаздывания воспроизведение и время запаздывания усечения, как и SCR в Exchange 2007 SP1. И, честно говоря, они работают практически одинаково, хотя управляются с помощью Set-MailboxDatabaseCopy команды.

Но в новой версии эти функции были улучшены и имеют отличия в Exchange 2010. Например, время запаздывания воспроизведения теперь можно устанавливать с максимальным значением до 14 дней, а не до 7 дней, как было в Exchange 2007 SP1. Также следует учитывать, что в отличие от SCR в Exchange 2007 SP1, время запаздывания воспроизведения в Exchange 2010 не имеет жестко запрограммированной задержки воспроизведения для 50 лог файлов (даже если задано значение в 0 секунд).

Как показано на рисунке 1 время запаздывания воспроизведения, как и время запаздывания усечения, отключены по умолчанию.

Цель времени задержки воспроизведения и усечения в Exchange 2010 практически такая же, что с SCR в Exchange 2007 SP1. Они используются для защиты от логических повреждений баз данных и хранения логических повреждений (ну, или, по крайней мере, от сохранения логических повреждений).

Зачастую организациям не требуются отсроченные копии баз данных, поскольку наличие нескольких не отсроченных копий для каждой базы почтовых ящиков в сочетании с возможностями восстановления отдельных объектов и политиками сохранения обычно бывает достаточно. Отсроченная копия базы данных представляет интерес только в редких случаях, когда организация сталкивается с логическими повреждениями, логическими повреждениями хранения (если говорить точнее), когда за логическое повреждение баз данных отвечает механизм определения потерь при очистке (lost flush detection mechanism), который представляет собой новое усовершенствование ESE баз данных в Exchange 2010. Этот механизм (в сочетании с функцией восстановления одной страницы баз данных (single database page restore)), по сути, обеспечивает хорошее состояние базы данных, что устраняет логические повреждения, которые могли возникать в базах данных предыдущих версий Exchange.

Логическое повреждение хранилища представляет собой ситуацию, когда определенная часть данных повреждена, а если говорить точнее, добавлена, удалена или изменена таким образом, которого пользователь не ожидал. Повреждение здесь, по всей видимости, является не совсем подходящим термином, поскольку логическое повреждение хранилища обычно возникает в ситуациях, когда серверные или клиентские приложения сторонних производителей выполняют ряд действительных MAPI операций с базой данных, что приводит к «повреждению» данных или потере значительного объема данных для конечного пользователя. Хотя функция восстановления отдельных объектов способна защитить от большинства сценариев логического повреждения хранилища, бывают редкие ситуации, когда более надежным способом восстановления данных является использование отсроченных копий баз данных, а не функция восстановления единичных объектов. Следует воспринимать отсроченные копии баз данных в качестве дополнительного «полезного» средства защиты.

Как на счет отсроченных баз данных публичной папки?

Поскольку базы данных публичных папок Exchange 2010 нельзя защитить с помощью непрерывной репликации, невозможно настроить отсроченные копии баз данных публичных папок.

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

Копии баз данных и усечение логов

Когда у нас имеется более одной копии базы данных почтовых ящиков, усечение логов будет вести себя иначе по сравнению с ситуацией, когда есть только одна копия базы данных. Поведение усечения логов в Exchange 2010 похоже с поведением этой функции в кластере на базе CCR в Exchange 2007. Усечение (удаление) лог файлов не зависит от времени запаздывания воспроизведения и усечения для копии базы данных.

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

• Все лог файлы были воспроизведены в две пассивные копии баз дынных
• Резервные копии базы данных/лог файлов были сделаны Exchange-совместимым приложением резервного копирования или циклическое ведение журнала было включено для базы данных почтовых ящиков. Поскольку цель этой статьи – показать вам, как традиционные резервные копии с точкой восстановления можно заменить, используя собственные функции Exchange 2010, мы, конечно же, включим функцию циклического ведения журналов (смотреть следующий раздел)
• Лог файлы должны быть ниже контрольной точки для базы данных (то есть минимальный лог файл требуется для восстановления)

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

• Лог файлы должны быть старше настроенных значений времени запаздывания воспроизведения и усечения
• Лог фалы должны быть усечены в активной копии базы данных

И не стоит беспокоиться, служба репликации Exchange Replication достаточно умна для того, чтобы знать, что она должна усечь лог файлы для всех не отсроченных копий, несмотря на то, что для отсроченной копии базы данных есть большая очередь воспроизведения. Логи должны быть обработаны механизмом осмотра в отсроченной копии.

Включение непрерывного циклического ведения журнала

Если вы выбираете работу без резервного копирования (этот термин здесь не совсем подходит, поскольку отсроченные копии баз данных можно считать резервным копированием с точками восстановления), лог файлы не будут усекаться, как это обычно бывает в решениях по резервному копированию и как уже говорилось в предыдущем разделе. Поэтому очень важно включить циклическое ведение журнала для всех баз данных, хранящихся на серверах почтовых ящиков. Это можно сделать, открыв страницу свойств для каждой базы данных. Здесь вам нужно нажать Обслуживание ('Maintenance') и отметить опцию включения циклического ведения журналов ('Enable circular logging'), как показано на рисунке 2.

Следует помнить, что есть значительная разница между включением циклического ведения журналов для базы данных, не защищенной DAG, и для базы, защищенной DAG. При включении циклического ведения журналов для DAG-защищенной базы данных, будет использоваться непрерывное циклическое ведение журнала. Смотрите предыдущий раздел о том, как усечение логов работает для DAG-защищенных баз данных.

Настройка отсроченной копии базы данных (Lagged Database Copy)

Итак, давайте настроим отсроченную копию базы данных, чтобы я смог показать вам, как эти копии работают и как с их помощью восстанавливать данные. В моей тестовой среде есть три копии баз данных для каждых 12 баз почтовых ящиков. Каждая копия баз данных хранится на своем отдельном диске 7200 RPM SATA. Говоря другими словами, я использую JBOD хранение. К тому же, я не использую резервных копий с точками восстановления для своих баз данных.

Для простоты я настрою отсроченную копию базы данных только для базы под названием MDB01. Первым шагом, кончено, будет добавление сервера почтовых ящиков, который будет хранить отсроченную копию базы данных, в группу DAG. В этой статье мы сделаем это с помощью графического интерфейса GUI. Итак, открываем консоль EMC, разворачиваем узел 'Конфигурация организации (Organization Configuration)', затем выбираем 'Mailbox' и переходим в закладку 'Database Availability Groups'. Здесь нажимаем правой клавишей на группе DAG и выбираем опцию управления принадлежностью к группе доступности баз данных '(Manage Database Availability Group Membership)' из контекстного меню. В результате откроется мастер, показанный на рисунке 3.

Здесь нажимаем Добавить ('Add') и выбираем сервер почтовых ящиков, который будет добавлен в группу DAG, после чего жмем 'OK'.

Через несколько минут мастер должен добавить сервер почтовых ящиков в группу DAG, как показано на рисунке 5.

Итак, пока все идет хорошо.

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

Get-MailboxDatabase MDB01 | FL

Как вы видите, три копии базы данных распределены по трем серверам почтовых ящиков и ни одна из них не является отсроченной.

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

Add-MailboxDatabaseCopy MDB01 'MailboxServer E2K10EX10 'ReplayLagTime 14.00:00:00

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

Отсроченная копия базы данных теперь настроена и с этого момента все лог файлы, генерируемые в активной копии базы данных, будут реплицироваться в две не отсроченные копии базы данных, а также в отсроченную копию базы данных. Если мы посмотрим на MDB01 в EMC, мы увидим, что длина очереди воспроизведения (Replay Queue Length) для отсроченной копии базы данных растет. На рисунке 8 показаны 422 лог файла, реплицированных в отсроченную копию базы данных, и каждый лог файл будет храниться в очереди воспроизведения в течение 14 дней.

На рисунке 9 и 10 также видно, что EDB файл для отсроченной копии базы данных меньше, чем для не отсроченных копий базы данных. Это, конечно, является следствием того, что 422 лог файла не были воспроизведены в отсроченную копию базы данных.

Блокирование активации для отсроченной копии базы данных

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

Чтобы заблокировать базу от активации, используется так называемая политика активации. Невозможно использовать консоль EMC для ее настройки, поэтому нужно использовать EMS для выполнения команды Suspend-MailboxDatabaseCopy с этой целью. Да, верно, обычно эта команда используется для приостановки репликации копии базы данных, но если выполнить ее со специальным параметром -ActivationOnly, можно заблокировать копию базы данных от активации.

В своей тестовой среде я собираюсь заблокировать отсроченную копию базы данных MDB01 (хранящуюся на E2K10EX10) от активации при любых аварийных ситуациях. Для этого я выполняю следующую команду:

Suspend-MailboxDatabaseCopy 'Identity MDB01\E2K10Ex10 -ActivationOnly

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

Resume-MailboxDatabaseCopy 'Identity MDB01\E2K10EX10

Итак, что если сервер Mailbox выделен под хранение отсроченных копий баз данных, и нам нужно заблокировать все базы данных на этом конкретном сервере в группе DAG от активации. Нам нужно будет выполнить вышеуказанную команду для всех отсроченных копий базы данных на сервере? К счастью нет. У нас есть схожая команда, которая работает на уровне сервера. Если нужно заблокировать участника группы DAG, используйте команду Set-MailboxServer с DatabaseCopyAutoActivationPolicy параметром.

Например, если вы хотите заблокировать члены группы DAG под названием E2K10EX10, чтобы копии его базы данных не активировались, используйте следующую команду:

Set-MailboxServer 'Identity E2K10EX10 - DatabaseCopyAutoActivationPolicy Blocked

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