Быстрое восстановление почтовой службы с помощью Recovery Storage Group

С точки зрения многих администраторов Exchange Server, самое тяжелое испытание — это крах базы данных, после которого пользователи теряют доступ к сообщениям электронной почты. Еще большая беда случится, если вслед за этим выйдут из строя ленточные средства хранения данных. Впрочем, администраторам становится не по себе уже при мысли об отказе службы обработки электронной почты. Чтобы вернуть пользователям возможность работы с электронной почтой, нужно прежде всего восстановить базу данных. Но дело в том, что современные хранилища почтовых ящиков зачастую бывают весьма объемными и для их восстановления требуется немало времени. Причем приступить к операции восстановления можно только после того, как будет устранена причина отказа, а она может быть связана со сбоями аппаратных компонентов, которые, с высокой долей вероятности, придется заменять. Словом, аварии базы данных вполне достаточно для того, чтобы на целый день отвлечь администратора от других дел.

Связь по каналам электронной почты является жизненно важной для нормальной работы многих организаций, поэтому при планировании развертывания систем Exchange нужно обязательно учитывать соображения, связанные с восстановлением данных после катастрофического сбоя. Можно, к примеру, в каждом важном узле сети устанавливать особый аварийный сервер и использовать его для восстановления баз данных и считывания информации из почтовых ящиков до тех пор, пока основной сервер не будет вновь введен в эксплуатацию. Это эффективное, но дорогостоящее решение, поскольку администраторам приходится разворачивать и обслуживать дополнительные аппаратные средства или срочно разыскивать необходимое оборудование в случае аварийного сбоя. Кроме того, такой подход предполагает реализацию параллельной службы Active Directory (AD) для обеспечения восстановления содержимого хранилищ почтовых ящиков на восстановительном сервере.

Было бы очень удобно, если бы все необходимые операции можно было выполнять на одном сервере, и именно такую возможность предоставляет реализованная в системе Exchange Server 2003 новая группа хранения Recovery Storage Group (RSG). RSG можно представить как специализированную версию обычной группы хранения SG (storage group), где размещается резервная копия хранилища почтовых ящиков. После этого можно с помощью диспетчера Exchange System Manager (ESM) приступить к работе с данными почтовых ящиков, которые содержатся в базе данных, загруженной в RSG. Чтобы объяснить, как пользоваться группами хранения RSG, я расскажу о некоторых важных деталях их реализации.

Архитектурные основы

Группы RSG стали реальностью благодаря двум фундаментальным достижениям. Прежде всего, речь идет о повышении мощности аппаратных средств; большинство эксплуатируемых ныне серверов могут с легкостью обеспечивать сетевые операции по сохранению и восстановлению данных и в то же время оказывать пользователям услуги с должным уровнем качества. Второе достижение — модификация архитектуры хранилища Store системы Exchange 2000 Server, которая позволяет Exchange обслуживать более одного хранилища почтовых ящиков на одном сервере. Новая архитектура обеспечивает размещение на одном сервере до 20 групп хранения SG, причем каждая из них обслуживает до пяти баз данных. Однако для работы с таким количеством баз данных требуется слишком большой объем памяти, поэтому корпорация Microsoft сократила максимальное число хранилищ до четырех. В версии Exchange 2000 используется специальная, пятая группа хранения SG для операций по сохранению данных, однако для того, чтобы познакомиться с полнофункциональной реализацией RSG, нам пришлось дожидаться выхода в свет версии Exchange 2003. Отметим, что, хотя версия Exchange 2003 Standard Edition обеспечивает функционирование лишь одной группы хранения SG, она тем не менее позволяет задействовать группу RSG.

Группы хранения RSG подобны обычным SG, но следует иметь в виду, что в Microsoft специально спроектировали их для временного использования при проведении операций по восстановлению данных, поэтому группы RSG нельзя использовать так же, как группы SG. Для снижения объема непроизводительных расходов при использовании RSG и для предотвращения помех в операционной среде многие функции RSG (такие, как средства доступа с помощью Internet-протоколов) отключены. К примеру, в хранилищах почтовых ящиков групп RSG нельзя создавать новые почтовые ящики. Не предусмотрена и возможность регистрации с помощью программы Outlook или других почтовых клиентов пользователей, которым нужно отправить почту либо обратиться к содержащимся в почтовых ящиках RSG сообщениям для решения других задач. Exchange не применяет системных политик к хранилищам почтовых ящиков RSG и не выполняет в этих хранилищах проводимые в фоновом режиме ежедневные операции по обслуживанию (такие, как дефрагментация по сети). Разумеется, в группах хранилищ RSG имеются почтовые ящики, но они представляют собой не более чем контейнеры для сообщений и присоединенных файлов, которые необходимо восстановить и переместить в обычное хранилище почтовых ящиков, функционирующее на данном сервере. По сути дела, существует только одна возможность обратиться к почтовому ящику RSG — с помощью реализованной в Exchange 2003 версии программы ESM или через служебную программу, например Exchange Server Mailbox Merge Wizard (ExMerge), которую можно загрузить по адресу http://www.microsoft.com/exchange/ downloads/2003/default.mspx

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

  • Атрибут msExchMailboxGUID используется для соединения пользователей (учетных записей AD) с почтовыми ящиками восстанавливаемой базы данных. Помните, что, в отличие от почтовых ящиков версии Exchange Server 5.5, почтовые ящики систем Exchange 2003 и Exchange 2000 определяются как набор свойств AD в учетной записи пользователя.
  • Атрибут msExchOrigMDB используется для того, чтобы проверить, можно ли подключить базу данных из резервного набора к достоверной базе данных, находящейся в той же административной группе, что и сервер RSG.

Существуют и другие средства восстановления почтовых ящиков конкретных пользователей. Если почтовый ящик удален по ошибке, его можно восстановить с помощью средства Mailbox Recovery Center диспетчера ESM (при условии, что администратор осознает допущенную ошибку и приступит к восстановлению почтового ящика до истечения срока хранения его содержимого — стандартный период составляет 30 дней). Если пользователи удалили какие-то нужные им объекты, они, как правило, могут восстановить эти объекты с помощью функции Recover Deleted Items клиента Outlook или инструмента Outlook Web Access (OWA). Если пользователи работают с другими клиентскими программами, такими как Outlook Express, операцию по восстановлению утерянных объектов может без труда выполнить администратор с помощью OWA. Разумеется, для успешного восстановления необходимо, чтобы пользователи пришли к заключению о невозможности обходиться без утерянного объекта еще до истечения периода его сохранения, но в большинстве компаний этот период составляет не менее 7 дней, а если пользователь в течение недели не замечал потери, то, может быть, удаленный объект не так уж ему и нужен.

Средства RSG позволяют выполнять операции восстановления данных во многих ситуациях, но они не обеспечивают восстановления сервера после катастрофического сбоя, поскольку для функционирования RSG требуется действующий сервер Exchange. Поясню эту мысль на примере. Если сервер требует полной переустановки после катастрофического сбоя, вы не сможете воспользоваться средствами RSG (сказанное не относится к ситуациям, когда в административной группе имеется еще один сервер). Вместо этого придется восстанавливать сервер, устанавливать операционную систему, разворачивать Exchange и затем выполнять типичную процедуру восстановления с помощью последней сохранившейся резервной копии. Еще одна ситуация, в которой администратор не может воспользоваться средствами RSG, — это восстановление данных общедоступной папки. Если администратор потерял данные из общедоступной папки, придется восстанавливать их с помощью резервной копии.

Временная почтовая служба с урезанными функциональными возможностями

В наши дни считается, что электронная почта — не роскошь, а насущная необходимость. Если почтовая служба выходит из строя, все хотят, чтобы она была восстановлена в кратчайшие сроки; точно так же люди реагируют на отключение телефона и перебои в подаче электричества или в водоснабжении. Обеспечить быстрое восстановление почтовой службы и призвана функция RSG. Она помогает системе Exchange быстро восстанавливать эту службу, чтобы пользователи могли приступить к отправке и получению электронных посланий намного раньше, чем если бы пришлось восстанавливать разрушенную базу данных на отдельном сервере, даже если им при этом придется ждать полного восстановления содержимого почтовых ящиков. Специалисты Microsoft называют эту функцию «урезанием возможностей»; имеется в виду, что служба быстро восстанавливается, но набор ее возможностей временно сокращается — до завершения операции полного восстановления. Для восстановления системы Exchange с помощью операции урезания возможностей средствами RSG необходимо выполнить следующие действия:

  1. Выявить и устранить неисправности базовых аппаратных средств, которые могли привести к отказу базы данных. Пытаться восстанавливать данные в условиях, когда не устранены неисправности оборудования, не имеет смысла.
  2. Если база данных все еще смонтирована, следует размонтировать ее и скопировать файлы поврежденной базы данных на накопители, расположенные в безопасном месте (они еще могут пригодиться для проведения диагностики), затем требуется удалить эти файлы с накопителей, на которых они хранились изначально. В большинстве случаев Store не сможет смонтировать такие базы данных по тем же самым причинам, которые вызвали аварийный сбой, поэтому-то и приходится копировать файлы. Не забудьте скопировать и регистрационные файлы транзакций.
  3. Попытаться смонтировать хранилище почтовых ящиков. Диспетчер ESM заметит отсутствие файлов и предложит создать новую базу данных, как показано на экране 1. Нужно принять это предложение, и Exchange приступит к созданию в рабочем каталоге нового (и пустого) хранилища почтовых ящиков, потокового файла и журналов регистрации транзакций.

В новой временной базе данных не будет никаких почтовых ящиков, но Exchange создаст их, как только в таких ящиках возникнет потребность (например, когда пользователь зарегистрируется для установления соединения и когда поступит сообщение для размещения в почтовом ящике). Некоторые администраторы рекомендуют посылать сообщения для всех почтовых ящиков поврежденной базы данных, форсируя тем самым создание системой Exchange новых почтовых ящиков. Если списка почтовых ящиков нет, можно создать его с помощью функции Export List диспетчера ESM (доступной через меню Action), но делать это следует лишь после восстановления базы данных в RSG. Здесь нужно иметь в виду еще одно обстоятельство: существующие правила, настроенные пользователями, такие как представления для папок, персональные формы, настройки OWA и настройки, регулирующие блокировку спама, после восстановления доступны не будут, поскольку они являются свойствами исходного почтового ящика. Об этом следует заранее предупредить пользователей — иначе они будут выражать недовольство в связи с тем, что почтовые ящики по непонятным причинам ведут себя странно. Пользователи вновь получат возможность работать со своими настройками, если переместить восстановленную базу данных на прежнее место в рабочий каталог, но об этом чуть позже.

Теперь пользователи смогут регистрироваться в системе и отправлять, а также получать почтовые сообщения. Доступа к сообщениям, хранящимся в отказавшей базе данных, у них не будет, но они смогут пользоваться почтовой службой с урезанными возможностями. Пользователям, работающим с пакетом Microsoft Office Outlook 2003 в режиме кэширования Exchange или с более ранней версией Outlook, использующей автономную папку-хранилище (offline folder store, OST), придется работать в сети или вновь создавать OST, потому что маркер Messaging API (MAPI) в OST старого клиента не соответствует глобальному уникальному идентификатору GUID почтового ящика этого пользователя в новой базе данных. В наши дни многие хранилища OST имеют весьма внушительные размеры, и перспектива воссоздания такого хранилища вряд ли кого-то вдохновит. Поэтому далее я расскажу о том, как свести эту проблему к минимуму.

  1. После того как система Exchange создаст новое хранилище почтовых ящиков и у пользователей появится возможность отправлять и получать сообщения, можно будет создать группу RSG. Для этого нужно правой клавишей мыши щелкнуть на имени сервера, на котором вы хотите разместить RSG, и выбрать New, Recovery Storage Group, как показано на экране 2. Каталоги RSG следует размещать на томах с достаточным объемом свободного дискового пространства - ведь в этих каталогах будут храниться восстановленные базы данных и журналы регистрации, извлеченные из резервных копий. Для обеспечения максимального быстродействия я рекомендую проследить за тем, чтобы восстановленные файлы не размещались на том же томе, где хранится старая база данных. Однако, если планируется переместить восстановленную базу данных обратно в рабочий каталог, нужно иметь в виду, что выполнение этой операции облегчается в том случае, если обе базы данных установлены на одном томе. Следует присвоить новой базе данных то же имя файла, которое было у старой базы данных, - это позволит избежать проблем, если потребуется вновь поместить восстановленную копию в рабочий каталог.
  2. Следующий шаг - добавление в RSG записи для вышедшей из строя базы данных. Для этого нужно выбрать RSG из списка хранилищ. Как показано на экране 3, Exchange сообщает версию выполняемого на сервере программного обеспечения (в данном случае это версия 7226, т. е. Exchange 2003 Service Pack 1 - SP1) и выводит список хранилищ почтовых ящиков, которые можно восстановить на целевом сервере.

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

  1. Чтобы восстановить физическую копию базы данных, можно либо скопировать соответствующие файлы в тот же каталог, который был указан для RSG, либо восстановить последнюю действующую копию вышедшей из строя базы данных в RSG. Вариант с восстановлением копии проходит лишь в том случае, если вы располагаете полной автономной резервной копией; в противном случае какие-то данные, скорее всего, будут потеряны. Перед началом операции по восстановлению необходимо убедиться, что в окне программы ESM установлен флажок This database can be overwritten by a restore. Чтобы избежать конфликтов между файлами, нужно удалить все следы базы данных, смонтированной в настоящее время в RSG; помимо прочего, следует удалить файлы этой базы данных и принадлежащие ей журналы регистрации транзакций. Если журналы регистрации, созданные с тех пор, как была снята последняя действующая копия, можно восстановить без воссоздания инкрементных резервных копий, установите флажок Last Restore Set, и после завершения восстановления Store сможет вновь выполнить эти транзакции по журналам регистрации в базе данных. В RSG имеется собственный набор журналов регистрации транзакций (их отличительный признак - префикс R00), поэтому Store сначала подключается к восстановленным журналам транзакций, завершает невыполненные транзакции, а затем устанавливает соединения с журналами регистрации RSG и выполняет последующие транзакции.

После успешного восстановления базы данных в RSG администратор может избрать один из двух вариантов дальнейших действий: переместить только что восстановленную базу данных обратно в рабочий каталог и вновь начать ее использовать либо возвратить информацию из базы данных, восстановленной в RSG, в почтовые ящики урезанной базы данных, которая находится в рабочем каталоге. Первый вариант возможен в тех случаях, когда пользователи еще не отправляли и не получали электронную почту через урезанную базу данных. Если же пользователи уже подключались к этой базе данных, то восстановление и слияние данных лучше проводить в фоновом режиме. Последний из упомянутых методов влияет на OST и на содержимое почтовых ящиков, поэтому следует выбрать время с относительно низкой загрузкой системы и переместить восстановленную базу данных в рабочий каталог, а урезанную базу данных — в группу хранилищ RSG. Логика здесь такая: пользователи хотят, чтобы их почтовые ящики были как можно скорее приведены к тому состоянию, которое они имели до сбоя, а между тем объем подлежащих обработке данных, содержащихся в урезанной базе данных, бывает существенно меньше.

Как решить проблему OST

Если действовать в соответствии со стандартными процедурами RSG и создать новую временную базу данных с целью последующего возобновления нормальной работы пользователей, они не смогут синхронизировать существующие хранилища OST с новыми почтовыми ящиками во временной базе данных, поскольку содержащиеся в OST идентификаторы MAPI ID не будут совпадать с MAPI ID нового почтового ящика. Пользователи смогут по-прежнему отправлять и получать сообщения по сетевым каналам, но у них не будет возможности работать в кэшированном режиме Exchange и они не получат доступа ни к сообщениям, хранящимся в старых почтовых ящиках, ни к настройкам последних. Пользователи могут организовать свою работу иначе — удалить свои старые хранилища OST и создать вместо них новые. Эти новые хранилища можно будет синхронизировать с почтовыми ящиками новой временной базы данных, кроме того, откроется возможность работы в кэшированном режиме Exchange. Но при этом пользователи опять-таки не будут иметь доступа к своим старым сообщениям, а также к правилам и разрешениям, применявшимся к прежним почтовым ящикам.

Если почтовые ящики пользователей невелики, можно будет без особых хлопот воссоздать OST «с нуля», но если в них содержатся значительные объемы данных (более 200 Мбайт), решить проблему будет сложно. Поэтому во многих случаях лучше идти другим путем: как можно быстрее вывести временную базу данных из рабочего каталога и заменить ее восстановленной базой данных; после этого идентификаторы MAPI ID будут совпадать, и пользователи смогут вернуться к нормальной работе. Разумеется, администратору еще придется восстанавливать и присоединять сообщения, созданные и отправленные пользователями в тот период, когда функционировала временная база данных, но эти сообщения, как правило, не столь многочисленны, и потребуется обрабатывать намного меньшие объемы данных и создавать намного меньше неудобств, нежели при использовании других методов.

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

  1. Создать в сети полную резервную копию временной базы данных.
  2. Отключить службу Information Store. В результате доступ ко всем хранилищам на сервере будет заблокирован, но тем не менее это самый безопасный способ гарантировать, что все базы данных были корректно закрыты и что все файлы доступны для копирования.
  3. Проверить, не было ли каких-либо сбоев в процессе закрытия временной и восстановленной баз данных. Проще всего это сделать с помощью утилиты Eseutil. Нужно запустить ее с ключом /mh (проверка заголовка базы данных) и проверить полученный результат на наличие подтверждения штатного завершения работы.
  4. Скопировать во временный каталог содержимое временной базы данных и ее файлов регистрации транзакций.
  5. Скопировать восстановленную базу данных и ее файлы регистрации транзакций из каталога RSG в рабочий каталог.
  6. Скопировать содержимое временной базы данных и ее файлов регистрации транзакций из временного каталога в каталог RSG.
  7. В окне диспетчера ESM для восстановленной базы данных и для временной базы данных выставить флажок This database can be overwritten by a restore option. Это необходимо для того, чтобы при повторном запуске Store она могла успешно смонтировать обе базы данных.
  8. Вновь активизировать службу Information Store. Теперь пользователи должны иметь доступ ко всем данным в своих почтовых ящиках - и к тем, которые были сохранены в последнем сеансе полного резервного копирования, и к тем, что содержатся в восстановленных инкрементных резервных копиях. Но пока что пользователи не могут обращаться к сообщениям, отправленным или полученным ими в период, когда эксплуатировалась временная база данных.
  9. Извлечь информацию о сообщениях из временной базы данных и переместить ее в почтовые ящики, размещенные в производственной базе данных. Ящики размещенной в RSG временной базы данных можно просматривать с помощью диспетчера ESM; нужно выбрать почтовые ящики, которые требуется восстановить, как показано на экране 4; затем с помощью программы ExMerge или мастера Exchange Task Wizard следует переместить содержимое почтовых ящиков временной базы данных в ящики функционирующей базы данных. Таким образом, пользователи получат полные копии своих почтовых ящиков. Более подробная информация об использовании мастера Exchange Task Wizard системы Exchange 2003 SP1 для объединения содержимого почтовых ящиков изложена во врезке "Exchange Task Wizard собирает почтовые ящики".

Группы хранения RSG — это важный этап в развитии технологии восстановления данных после катастрофических сбоев в системах Exchange. К сожалению, не приходится сомневаться, что в процессе развертывания непременно произойдет отказ того или иного компонента. Конечно, за последние несколько лет надежность технологии хранения данных значительно повысилась. Но поскольку всякая неисправность в системе хранения данных, если она затрагивает хранилище почтовых ящиков, оборачивается резким снижением эффективности работы пользователей, можно только приветствовать любое усовершенствование, позволяющее быстро восстановить вышедшую из строя службу. Средства RSG прекрасно удовлетворяют эту потребность. Но, как известно, ни одна технология не свободна от недостатков. Вот и у RSG есть, так сказать, свои причуды, и каждый, кто хочет эффективно пользоваться этой системой, должен хорошо разбираться в ее механизме. Более подробные сведения о том, что нужно знать администраторам об RSG, содержатся во врезке «Недоработки RSG». Отмечу только, что весьма полезно поэкспериментировать с RSG на тестовом сервере — особенно в выполнении таких операций, как извлечение данных и перемещение их обратно в почтовые ящики пользователей.

Тони Редмонд - Редактор издания Windows IT Pro, старший технический редактор Exchange & Outlook Administrator, вице-президент и главный технолог HP Services. exchguru@windowsitpro.com

Exchange Task Wizard собирает почтовые ящики

Компания Microsoft внесла важное изменение в компонент Recovery Storage Group (RSG) в пакете обновлений Exchange Server 2003 Service Pack 1 (SP1), устранив необходимость в использовании утилиты ExMerge для извлечения данных почтовых ящиков из восстановленной базы данных и слияния их с активной базой данных. Теперь эти операции можно выполнить напрямую с использованием функции Recover Mailbox Data мастера Exchange Task Wizard в диспетчере Exchange System Manager (ESM). Это более аккуратный способ восстановления данных, при котором не нужно иметь экземпляры утилиты ExMerge и отслеживать изменения, вносимые в эту утилиту Microsoft. Как показано на экране A, с помощью Recover Mailbox Data можно объединить или копировать восстановленные данные в целевые почтовые ящики. При слиянии данных мастер перемещает данные в целевую папку, предварительно убедившись, что эти элементы в папке отсутствуют. Мастер проверяет значения свойств PR_SEARCH_KEY и PR_LAST_MODIFICATION_TIME MAPI, чтобы выяснить, существует ли в целевом почтовом ящике элемент, поступивший из базы данных RSG, и если это так, то является ли он более новым, чем экземпляр в целевом почтовом ящике. Если элемент обновлен, то он используется, в противном случае — игнорируется. При копировании данных мастер строит полную копию иерархии папок восстановленного почтового ящика в целевом почтовом ящике под корневой папкой с именем Recovered Data и копирует все сообщения из почтового ящика в базе данных RSG в эти папки. В большинстве случаев предпочтительно слияние данных, так как появление новых папок может запутать пользователей и привести к дополнительным обращениям в справочную службу.

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

Как и при использовании функции Move Mailbox мастера Exchange Task Wizard, можно запланировать восстановление почтовых ящиков в нерабочее время. Как показано на экране B, мастер сохраняет результаты обработки в файле XML-формата в каталоге My DocumentsExchange Task Wizard Logs. К сожалению, данные представлены в «сыром» формате XML, а не в удобно отформатированном отчете, но тем не менее прочитать их легко.

Мастер игнорирует испорченные элементы в почтовом ящике и обрабатывает только корректные данные. В отличие от ExMerge, мастеру не требуется полномочий send as и receive as в папке назначения. Единственный недостаток Exchange Task Wizard — невозможно фильтровать элементы, как в утилите ExMerge. Однако в большинстве случаев требуется восстанавливать ящики целиком, поэтому фильтровать данные не нужно.

Недоработки RSG

Перед использованием RSG необходимо учесть рабочие харктеристики функции.

  • Нельзя восстанавливать общедоступные папки в RSG - функция работает только с почтовыми ящиками.
  • Если в сервере присутствует RSG, то Exchange Server автоматически направляет все восстановительные операции в RSG. Если нужно выполнить типовое восстановление и предпринимается попытка восстановить базу данных, которой нет в RSG, то Exchange сообщает об ошибке 9634 Failed to find a database in the Recovery Storage Group, что логично. Чтобы предотвратить проблемы с типовыми операциями восстановления, следует удалить RSG из сервера, после того как потребность в инструменте исчезнет. Однако, если желательно сохранить RSG, можно создать параметр Recovery SG Override типа DWORD в разделе реестра _LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeISParametersSystem и присвоить ему значение 1, чтобы утилиты, использующие API резервного копирования Exchange, игнорировали RSG.
  • MAPI - единственный протокол, который можно задействовать для доступа к данным в хранилище почтовых ящиков RSG. Однако в программах MAPI должны быть учтены особенности структуры и соединений, существующих между RSG и данными в хранилище почтовых ящиков. Как и Exchange System Manager (ESM), версия ExMerge, распространяемая с Exchange 2003, настроена на работу с RSG. Как правило, следует всегда использовать новейшие версии этих утилит - версия ESM в пакете Exchange Server 2003 Service Pack 1 (SP1) лучше, чем в Exchange 2003.
  • Нельзя применять RSG для восстановления почтовых ящиков удаленных пользователей или пользователей, переведенных в другую группу хранения.
  • В кластерах допускается только один RSG на виртуальный сервер Exchange. Хранилища почтовых ящиков можно восстанавливать из автономных серверов в RSG в кластере, при условии что серверы входят в ту же административную группу, что и кластер.
  • Можно восстановить базу данных в RSG на другом сервере в той же административной группе. Однако имена базы данных и группы хранения в исходном и целевом серверах должны совпадать. Если имена не совпадают, следует воспользоваться рекомендациями, приведенными в статье Microsoft "You cannot restore a mailbox store from one Exchange 2003 server to a Recovery Storage Group on another Exchange 2003 server" по адресу http://support.microsoft.com/?kbid=836554 и повторить попытку.
  • Хотя RSG работает только на сервере Exchange 2003, можно соединять базы данных с любого сервера с административной группой, в том числе сервера Exchange 2000 Server SP3 и более поздних версий. Однако при использовании RSG для восстановления данных из этих баз данных Store автоматически обновляет версию базы данных до версии, используемой сервером, на котором размещен RSG. Таким образом, нельзя переключить восстановленную базу данных на первоначальный сервер, если не модернизировать его до той же версии Exchange. В основном по той же причине нельзя использовать RSG для восстановления данных с сервера, работающего с более новой версией Exchange.
  • Компания Microsoft опубликовала превосходный документ, содержащий много рекомендаций и описаний приемов для использования RSG на предприятии. Более подробная информация приведена в статье Microsoft "The 'Using Exchange Server 2003 Recovery Storage Groups' book for Microsoft Exchange Server 2003 is available" по адресу http://support.microsoft.com/?kbid=836452.