Резервная непрерывная репликация в Exchange Server 2007 с пакетом обновления 1

В пакете обновления 1 для Exchange 2007 предусмотрено несколько новых функций. Одна из них — резервная непрерывная репликация (SCR) — обеспечивает повышенную устойчивость и дублирование данных в центрах данных. Из названия этой функции ясно, что она предназначена

для ситуаций, когда используются резервные серверы восстановления.

Если вы знакомы с основной коммерческой версией Exchange 2007 (RTM), то вы знаете, что в ней также поддерживается повышенная устойчивость и дублирование посредством доставки журналов, а также кластеры Windows® для переключения при сбое. В этой версии доставка журналов (ее официальное название — непрерывная репликация) доступна в двух видах: локальная непрерывная репликация (LCR), приведенная на рис. 1, и кластерная непрерывная репликация (CCR), приведенная на рис. 2.

Figure 1 Local continuous replication

Figure 2 CCR is log ship

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

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

!В коммерческой версии Exchange 2007 (RTM) поддерживается дублирование в центре данных и устойчивость узлов, но поскольку репликация LCR и CCR поддерживает только одну копию каждой базы данных, приходится выбирать между дублированием и устойчивостью. В качестве примера рассмотрим функции доступности данных и служб в CCR. Развертывание активного и пассивного узлов в одном центре данных обеспечивает доступность службы и данных в этом центре данных, но не обеспечивает устойчивости (поскольку оба узла находятся физически в одном месте). Развертывание активного узла в одном центре данных, а пассивного узла — во втором центре данных обеспечивает устойчивость, но не обеспечивает доступность в центре данных, так как пассивный узел, обеспечивающий доступность, находится в другом центре данных).

В пакете обновления 1 поддерживается репликация SCR. Такая репликация позволяет создать дополнительные копии каждой базы данных, а значит, высокая доступность и устойчивость не исключают друг друга. Например, как показано на рис. 3, можно использовать SCR вместе CCR для локальной репликации групп хранения в основном центре данных (используя CCR для обеспечения доступности) и для удаленной репликации во втором или резервном центре данных (используя SCR для обеспечения устойчивости). Во втором центре данных находится резервный кластер, который можно активировать и быстро настроить в качестве дублирующего кластерного сервера почтовых ящиков при восстановлении узла.

Figure 3 CCR deployed in Redmond datacenter and SCR deployed in Quincy datacenter

На рис. 3 показана структура развертывания в организации с двумя центрами данных, каждый с собственным узлом Active Directory®: Redmond и Quincy. Узел Redmond находится в основном (рабочим) центре, а узел Quincy находится во втором (резервном) центре данных. На узле Redmond развертывается репликация CCR для обеспечения дублирования. Целевые объекты SCR и элементы инфраструктуры, необходимые для Exchange 2007, настраиваются на резервном кластере на узле Quincy для обеспечения устойчивости. К дополнительным элементам инфраструктуры относятся: сервер клиентского доступа, транспортный сервер-концентратор, сервер Active Directory, DNS-сервер и сервер доступа к Интернету. Эти элементы могут быть выделенными или совместными ресурсами. Выделенные ресурсы поддерживают только пользователей центра данных, в котором находятся эти ресурсы. Совместные ресурсы поддерживают пользователей и локального центра данных, и других центров данных. Решение о том, следует ли применять выделенные или совместные ресурсы, зависит от потребностей вашей организации. Дополнительные сведения о таких ресурсах см. в разделе справки Exchange Server 2007 «Site Resilience Configurations» по адресу technet.microsoft.com/bb201662.aspx. Обратите внимание на использование нового типа кворума — набора узлов большинства (MNS). В Exchange Server 2007 репликация CCR использует кворум MNS и файловый ресурс-свидетель (FSW) вместо традиционного узла голосования, как показано на рис. 3.

На рис. 4Изображена среда с CCR и SCR. Эта среда обеспечивает несколько уровней дублирования для почтовых ящиков и служб, размещенных на сервере EXCLUS1. Эти почтовые ящики защищены от критических сбоев любого масштаба.

Figure 4 Standalone mailbox servers using SCR to replicate storage groups to each other

Репликация SCR также может использоваться в небольших и средних организациях. Например, как показано на рис. 4, в организации можно развернуть два отдельных сервера почтовых ящиков (EXMBX1 и EXMBX2) и использовать SCR для репликации некоторых или всех групп хранения с одного сервера на другой.

В этом примере EXMBX1 и EXMBX2 — рабочие серверы с пятью активными группами хранения. Каждая группа хранения является исходным объектом SCR для целевого объекта SCR на другом сервере. В случае сбоя хранилища или любого другого события, при котором группа хранения, настроенная в качестве исходного объекта SCR, станет недоступной, можно быстро активировать копию целевого объекта SCR с помощью нескольких административных задач оболочки управления Exchange. При использовании Microsoft® Office Outlook® 2007 и функций переноса базы данных и автообнаружения Exchange 2007 время простоя при сбое активной группы хранения (или нескольких активных групп хранения) составит всего несколько минут.

Исходные и целевые объекты SCR

Как и в LCR и CCR, в репликации SCR также используются понятия активной и пассивной копий группы хранения, но в SCR они называются соответственно исходными и целевыми объектами. Тем не менее, исходные и конечные объекты SCR представляют собой копии группы хранения. (Для SCR невозможно включить группы хранения для восстановления.)

Начальная точка SCR (исходный объект SCR) — это любая группа хранения на отдельном сервере почтовых ящиков или на кластерном сервере почтовых ящиков в одной копии кластера или среды CCR. Следует отметить, что хотя исходным объектом SCR может служить кластерный сервер почтовых ящиков, репликация SCR сама по себе не является кластерным решением и для нее не требуется служба кластеров Windows. Конечной точкой (целевым объектом) SCR может быть либо отдельный сервер почтовых ящиков, либо узел в отказоустойчивом кластере с установленной ролью почтового ящика, без настроенного кластерного сервера почтовых ящиков.

Взаимоотношения между исходными и целевыми объектами

Каждой исходной группе хранения SCR может соответствовать неограниченное число целевых объектов SCR. Например, у исходной группе хранения может быть один целевой объект в том же самом центре данных и второй целевой объект в другом центре данных. Однако рекомендуется использовать не более четырех целевых объектов на каждый исходный объект. Если требуется использовать более четырех объектов, это приведет к повышенной нагрузке на ресурсы исходного сервера SCR (память, ЦП и место на диске). Это следует учесть при планировании архитектуры этого сервера. У каждого целевого компьютера SCR может быть несколько исходных серверов. И на исходных, и на целевых компьютерах должен быть установлен пакет обновления 1 для Exchange 2007. Операционная система также должна поддерживаться пакетом обновления 1 для Exchange 2007 (к примеру, это может быть Windows Server® 2008 или Windows Server 2003 с пакетом обновления 2). Впрочем, вне зависимости от используемой операционной системы в SCR не поддерживаются различные системы одновременно: операционная система на исходном сервере SCR должна быть такой же, как и на всех целевых серверах. Таким образом, если исходный сервер SCR работает под управлением Windows Server 2003, то и на всех целевых серверах SCR также должна быть ОС Windows Server 2003.

Репликация SCR доступа в выпуске Exchange 2007 Standard Edition. Если в качестве исходного сервера используется кластерный сервер почтовых ящиков в среде SCR или CCR, то требуется выпуск Exchange 2007 Enterprise Edition. Каждый целевой объект SCR поддерживает до 50 экземпляров (50 реплицированных групп хранения) при использовании выпуска Enterprise Edition и до 5 экземпляров при использовании выпуска Standard Edition.

Также следует соблюдать требования целевых объектов SCR. Прежде всего, и исходный и целевой компьютеры должны находиться в одном и том же домене Active Directory, хотя они могут быть на разных узлах Active Directory. Кроме того, пути базы данных и файлов журнала в исходной системе и во всех целевых системах должны совпадать для каждой группы хранения, реплицируемой с помощью SCR. И наконец, если узел или сервер настроен в качестве целевого объекта SCR, невозможно включить LCR для любой группы хранения на целевом компьютере SCR и невозможно добавить кластерные серверы почтовых ящиков в резервный отказоустойчивый кластер.

Сравнение SCR, CCR и LCR

В репликации SCR (см. рис. 5) используется та же технология доставки журналов, как и в LCR и CCR, для предоставления новых возможностей развертывания и конфигураций. Как и в LCR и CCR, группы хранения с поддержкой SCR могут содержать только одну базу данных. Кроме того, SCR нельзя использовать для базы данных общих папок, если в организации Exchange существует несколько баз данных общих папок.

Figure 5 SCR is log shipping to another server or a passive node in a failover cluster

Одно из основных отличий заключается в том, что SCR поддерживает несколько целевых объектов в группе хранения, тогда как в LCR и CCR поддерживается только один целевой объект (пассивная копия). Еще одно важное отличие состоит в том, что нельзя создать резервную копию копии SCR, в отличие от CCR и LCR. При использовании SCR заголовки баз данных целевых объектов SCR обновляются, а файлы журналов обрезаются при резервном копировании исходной группы хранения SCR (или, при использовании CCR и LCR, при резервном копировании активных или пассивных копий исходной группы хранения SCR).

Как в LCR и CCR, доставка журнала в SCR является непрерывной и использует модель получения. Как только новый файл журнала закрывается и получает следующий порядковый номер, служба репликации Microsoft Exchange, работающая на целевом компьютере SCR, получает закрытые файлы журнала транзакций с исходного компьютера SCR, проверяет их и затем перемещает в соответствующую папку файлов журнала на целевом компьютере SCR.

Запаздывание воспроизведения

После копирования файлов журналов на целевой компьютер репликация SCR делает то, что не выполняется при репликации LCR и CCR. Вместо немедленного воспроизведения файлов журналов в копию базы данных в SCR начинается встроенная задержка воспроизведения 50 файлов на 24 часа. В SCR можно указать дополнительное время задержки, помимо этого времени по умолчанию. Это может пригодиться в разных ситуациях. Например, в случае логического повреждения активной базы данных задержка на 24 часа может исключить логическое повреждение целевой базы данных.

Длительность задержки воспроизведения управляется администратором с помощью параметра ReplayLagTime, который определяет, сколько времени служба репликации Exchange должна ждать перед воспроизведением файлов журнала, скопированных на целевой компьютер. Используется формат Дни.Часы:Минуты:Секунды, значение по умолчанию — 24 часа. Наибольшее допустимое значение — 7 дней. Наименьшее допустимое значение — 0 секунд. Если установить это значение, то воспроизведение файлов журналов произойдет сразу по истечении задержки по умолчанию для 50 файлов.

В дополнение к параметру ReplayLagTime в Exchange предусмотрена встроенная задержка на 50 файлов журнала, которая не зависит от значения параметра. Чтобы определить, когда следует воспроизводить файл журнала, в Exchange используется большее из двух значений: либо значение параметра ReplayLagTime, либо x файлов журнала, где x=50. Это дополнительная мера предосторожности, предусмотренная для того, чтобы не нужно было заново распространять группу хранения в случаях, когда в исходной системе SCR с непрерывной репликацией (например кластерный сервер почтовых ящиков в среде CCR) возникает сбой и необходимо восстановить работу одной или нескольких групп хранения с помощью командлета Restore-StorageGroupCopy. (Распространение — это использование интерфейсов API потокового копирования расширенного обработчика хранилищ (ESE) для создания рабочей копии исходной базы данных SCR на целевом компьютере SCR.) Задержка воспроизведения снижает необходимость повторного распространения копий SCR, поскольку по природе работы SCR в случае ошибок в исходной системе две копии будут выполнены с незначительным интервалом между ними.

Запаздывание усечения

В коммерческой версии Exchange 2007 (RTM) в среде с непрерывной репликацией применяется следующее правило: файл журнала невозможно удалить, если он не был скопирован и воспроизведен в копии базы данных. При использовании SCR это правило изменяется. Репликация SCR (обеспечивающая возможность нескольких копий базы данных) допускает усечение файлов журнала на исходном компьютере, как только они проанализированы всеми целевыми компьютерами. При усечении журнала исходный сервер не ждет воспроизведения всех журналов на всех целевых объектах, поскольку в копиях целевых объектов может быть настроена разная длительность задержки воспроизведения.

Можно указать дополнительную задержку усечения журнала с помощью нового параметра TruncationLagTime, который указывает, сколько времени служба репликации Exchange должна ждать (используется формат Дни.Часы:Минуты:Секунды) перед усечением файлов журнала, скопированных на целевой компьютер и воспроизведенных в копии базы данных. Отсчет времени начинается сразу после успешного воспроизведения файлов журнала в копии базы данных. Наибольшее допустимое значение — 7 дней, наименьшее — 0 секунд. Если установить последнее значение, задержка усечения файлов журнала отключается.

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

В среде с репликацией LCR или CCR, дополненной репликацией SCR, файл журнала в целевой системе SCR будет усечен при выполнении следующих четырех условий: 1) существует резервная копия файла журнала; 2) порядковый номер файла журнала меньше контрольной точки для группы хранения; 3) пассивная копия группы хранения находится в состоянии, допускающем усечение файла журнала; 4) все целевые объекты SCR исследовали файл журнала.

Включение и управление резервной непрерывной репликацией

Резервная непрерывная репликация (SCR) включается с помощью командлета Enable-StorageGroupCopy в командной консоли Exchange, в которую в пакете обновления 1 добавлены некоторые новые параметры. Как описано выше, с помощью параметров ReplayLagTime и TruncationLagTime можно управлять поведением объектов репликации SCR. Еще один параметр, SeedingPostponed, можно использовать, чтобы пропустить первоначальное распространение целевого объекта репликации. Это может пригодиться в разных ситуациях. Предположим, база данных в группе хранения, где поддерживается репликация SCR, имеет размер 100 ГБ. Нецелесообразно разрешать передачу 100 ГБ данных по сети компании во время пиковой загрузки. С помощью параметра SeedingPostponed можно включить SCR немедленно, а распространить данные позднее. В последствии можно будет вручную выполнить распространение с помощью командлета Update-StorageGroupCopy.

Перечисленные выше параметры необязательны, но для SCR обязателен один параметр командлета: StandbyMachine. В нем указывается имя компьютера, который будет содержать целевой объект репликации. Значение этого параметра указывается как часть значения атрибута msExchStandbyCopyMachines группы хранения, для которой поддерживается репликация SCR. Атрибут msExchStandbyCopyMachines — это строка в формате Юникод с несколькими значениями, добавляемая в схему Active Directory при введении Exchange 2007 SP1 в организацию Exchange. Это одна из причин, по которой при установке пакета обновления 1 требуется обновление схемы Active Directory.

Параметр StandbyMachine является важнейшим для SCR. Некоторые командлеты в пакете обновления 1 были изменены с целью использовать этот параметр для поддержки и управления целевыми объектами SCR. Изменения командлетов описаны на рис. 6.

Figure 6  Cmdlets that use the Stand­by­Machine parameter

Командлет	Описание
Disable-StorageGroupCopy	Отключает назначение репликации SCR для группы хранения.
Get-StorageGroupCopyStatus	Определяет текущее состояние назначения репликации SCR.
New-StorageGroup	Создает новую группу хранения с поддержкой SCR, при этом не требуется отдельно включать SCR с помощью командлета Enable-StorageGroupCopy.
Restore-StorageGroupCopy	Отключает SCR и делает базу данных назначения SCR пригодной для присоединения с помощью операции Mount-Database в процедуре восстановления.
Resume-StorageGroupCopy	Восстанавливает непрерывную репликацию для группы хранения, в которой она была приостановлена.
Suspend-StorageGroupCopy	Приостанавливает непрерывную репликацию для группы хранения, в которой она была включена.
Update-StorageGroupCopy	Используется для заполнения целевой группы хранения SCR.

Активация целевых объектов репликации SCR

Резервная непрерывная репликация обеспечивает наличие одной или нескольких своевременных копий данных, которые можно использовать при утрате или повреждении исходных данных. Процесс создания копии целевого объекта SCR и ее повторная подготовка в виде рабочей базы данных называется активацией. Активация выполняется в рамках процесса восстановления, который может происходить в двух вариантах (/m:RecoverServer — восстановление одного сервера, /RecoverCMS — восстановление кластерного сервера почтовых ящиков).

Как можно использовать SCR

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

В организации развернуты серверы Exchange 2007 с пакетом обновления 1 и применяется SCR для копирования группы хранения на удаленном сервере почтовых ящиков. Оба сервера почтовых ящиков (исходный сервер и целевой сервер) находятся на одном и том же узле Active Directory и настроены для использования встроенных в Active Directory DNS-серверов. Интервал репликации Active Directory равен 15 минутам.

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

Репликация SCR настроена таким образом, что файлы журналов транзакций реплицируются для одной группы хранения SG1, содержащей одну базу данных MBX1. Пути к файлам группы хранения и к файлу базы данных — C:\SG1 и C:\SG1\MBX1.EDB. В этом случае EXMBX1 является источником, а EXMBX2 — целевым объектом SCR. Эта система была настроена следующим образом:

Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

После включения SCR было проверено состояние SCR для SG1 с помощью командлета Get-StorageGroupCopyStatus:

Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2

Чтобы сэкономить время при активации целевого объекта SCR, на сервере EXMBX2 была заранее настроена группа хранения SG1PORT и база данных MBX1PORT, которые будут использоваться для переноса. SG1PORT и MBX1PORT отделены от целевой группы хранения и файлов базы данных. Поэтому для SG1PORT и MBX1PORT указывается временный путь, не конфликтующий с путями целевых объектов SCR. SG1PORT и MBX1PORT будут использоваться только для переноса базы данных; сами по себе файлы базы данных и группы хранения SG1PORT не нужны. Поэтому администратор отсоединяет базу данных MBX1PORT и удаляет все ее файлы в группе хранения. Объекты группы хранения и базы данных остаются в Active Directory, поскольку они будут использованы для переноса базы данных в процессе восстановления.

Активация и восстановление

Журнал событий приложения указывает, что исходная база данных SCR физически повреждена. Поскольку SCR-репликация была включена для SG1, принимается решение активировать целевую базу данных SCR для SG1 вручную и восстановить доступность данных. Активация целевой копии SCR начинается с отсоединения MBX1 в SG1 с помощью следующего командлета:

Dismount-Database EXMBX1\SG1\MBX1

После этого целевая база данных SCR подготавливается к подключению, а почтовые ящики переносятся с MBX1 на MBX1PORT.

Для отключения SCR и подготовки целевой базы данных SCR к подключению используется командлет Restore-StorageGroupCopy. При этом база данных группы хранения помечается как присоединяемая и предоставляется отчет о потере данных, который будет вызван присоединением базы данных в группе хранения. Также проверяется наличие в расположении группы хранения пассивной копии всех файлов журналов, созданных активной копией группы хранения. Если каких-либо файлов не хватает, будет предпринята попытка их скопировать. Следующий командлет используется для подготовки целевой базы данных SCR к присоединению:

Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

В этом примере файлы журнала из исходной группы хранения SCR доступны для копирования. Если эти файлы недоступны (например, если компьютер выключен), к задаче Restore-StorageGroupCopy нужно добавить параметр Force. Если этого не сделать, задача Restore-StorageGroupCopy будет пытаться подключиться к исходной группе хранения для копирования недостающих файлов журнала, а если исходная группа хранения будет недоступна, задача Restore-StorageGroupCopy не будет выполнена и база данных не будет подготовлена к присоединению. Параметр Force означает, что исходные файлы недоступны; задача Restore-StorageGroupCopy не пытается подключиться и подготавливает базу данных к присоединению.

После завершения работы команды Restore-StorageGroupCopy администратор должен убедиться, что база данных находится в состоянии чистого отключения. Если база данных находится в состоянии «неправильного отключения» (см. technet.microsoft.com/aa996757.aspx), ее нужно перевести в состояние чистого отключения. Если префикс файла журнала группы хранения (например E00 или E01) одинаков для источника SCR (EXMBX1\SG1) и для группы хранения назначения SCR (SG1PORT), которая будет использоваться для переноса базы данных (EXMBX2\SG1PORT), то запускать программу Eseutil в режиме восстановления не требуется. Последняя операция присоединения базы данных приведет ее в состояние чистого отключения после анализа всех реплицированных файлов журнала. Если база данных не находится в состоянии чистого отключения, нужно запустить программу Eseutil в режиме восстановления (Eseutil /r).

После того, как база данных будет приведена в состояние чистого отключения, нужно запустить две команды, которые указывают в Active Directory новое расположение файлов группы хранения и файла базы данных. Эти команды изменяют пути к SG1PORT и MBX1 с исходных на промежуточную группу хранения и базу данных (SG1PORT и MBX1PORT):

Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath C:\SG1\MBX1PORT.EDB –ConfigurationOnly

В указанные выше команды нужно включить параметр –ConfigurationOnly, чтобы в Active Directory были обновлены только параметры конфигурации для этих объектов. Файлы и данные не перемещаются: этого не требуется, поскольку данные уже реплицированы в папку C:\SG1 на сервере EXMBX2.

Теперь нужно настроить базу данных (MBX1PORT), чтобы разрешить ее замену при восстановлении. Для этого нужно установить флажок «База данных может быть перезаписана при восстановлении» в свойствах объекта базы данных в консоли управления Exchange или выполнить следующую команду в оболочке управления Exchange:

Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true

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

Mount-Database EXMBX2\SG1PORT\MBX1PORT

После присоединения базы данных почтовые ящики, связанные исходной базой данных (SG1\MBX1) нужно связать с MBX1PORT на EXMBX2. Для этого следует запустить командлет Get-Mailbox и направить его выходные данные командлету Move-Mailbox. При этом важно, чтобы системный помощник Exchange и системные почтовые ящики не были включены в выходные данные командлета Get-Mailbox, направляемые командлету Move-Mailbox. Эти объекты не нужно перенаправлять. Следующая команда служит для перенаправления всех почтовых ящиков пользователей и исключения системных почтовых ящиков:

Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox| ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT

На этом этапе клиенты могут получить доступ к MBX1PORT. Однако доступ пользователей к своим почтовым ящикам после их перемещения с EXMBX1\SG1\MBX1 на EXMBX2\SG1PORT\MBX1PORT зависит от скорости репликации Active Directory, то есть от количества серверов каталогов и от того, сколько времени им требуется для распространения изменений. Кроме того, доступ зависит и от используемых клиентских программ. Клиенты Outlook 2007 и отличные от Outlook получат доступ к почтовым ящикам пользователей после того, как в серверах каталогов, используемых сервером клиентского доступа пользователей, будут указаны новые пути. Для клиентов Outlook 2003 и более ранних версий потребуется обновить профиль системы сообщений на настольных ПК пользователей, указав новое имя сервера.

Заключительные действия

Итак, теперь клиенты имеют доступ к своим почтовым ящикам. Нужно восстановить возможность дублирования, заново включив резервную непрерывную репликацию. Для этого нужно удалить с EXMBX1 все оставшиеся группы хранения и файлы баз данных. После этого можно переместить пути для EXMBX1\SG1\MBX1 во временное расположение, а EXMBX1 может стать объектом репликации для EXMBX2.