Recovery Storage Groups (RSG – группы для восстановления хранилища) – это одна из самых важных возможностей для администратора сервера Exchange Server 2003 SP1. Если вы уже использовали эту функцию, то у вас могли возникнуть те же вопросы, которые возникли у меня. В этой статье я постараюсь ответить на эти вопросы.
Введение
Recovery Storage Groups – одна из самых важных возможностей для администратора сервера Exchange Server 2003 SP1. Раньше, до появления Exchange 2003 SP1, если вам необходимо было восстановить ящик электронной почты, вы должны были выполнить большой объем работы. Вы должны были настроить полностью отдельный лес (forest) с помощью сервера восстановления Exchange recovery server и восстановить его на этом сервере. После этого вы должны были экспортировать в PST, а затем импортировать этот PST в промышленный почтовый ящик. Не очень увлекательно, и я знаю далеко не одно место, в котором политики настроены не восстанавливать почтовые ящики. Вы можете представить, к чему это приведет.
Recovery Storage Groups позволяют администратору устанавливать восстановленную копию базы данных Exchange database на любой сервер, входящий в состав той же самой административной группы (Administrative Group). После восстановления базы данных в RSG, у администратора появляются несколько настроек для восстановления почтовых ящиков на промышленном сервере. Вы можете восстановить почтовый ящик, группу почтовых ящиков или всю базу данных.
Чем отличаются RSG?
Первое и самое важное отличие заключается в том, что RSG не поддерживает ни одного протокола, за исключением MAPI, и поэтому не может посылать или получить письма. Их также нельзя связать с учетной записью пользователя в Active Directory. В действительности единственный способ для получения доступа к почтовому ящику, находящемуся в RSG – с помощью ExMerge. Другой способ, кроме ExMerge, это восстановить его на промышленном хранилище сервера.
Т.к. RSG нельзя использовать в промышленных масштабах, то существует ряд пунктов, которые они не поддерживают, например, поддержку в режиме реального времени, дефрагментацию, управление почтовым ящиком и системные политики. В отличие от регулярных групп хранения (regular storage group), вы не можете изменять размещение файлов. Когда вы создаете RSG, вы можете использовать размещение по умолчанию или указать свое расположение для файлов (смотрите Рисунок 1). Единственный способ изменить это, заключается в удалении RSG и создании его заново.
Некоторые вещи, которые отличают RSG это:
- Вы не можете использовать RSG для восстановления общих папок
- Для одного сервера Exchange поддерживается только одна группа RSG
Как работает восстановление?
После того, как вы создали RSG, и собираетесь приступить к процессу восстановления, вы, вероятно, заметите, что у вас не спросили, куда восстановить базу данных. В результате этого некоторые администраторы спешат прервать восстановление, думая, что они делают что-то неверно. Например, при восстановлении с помощью NTBackup, единственная информация, которая от вас потребуется – это указать, куда восстанавливать и размещение временных файлов (смотри Рисунок 2).
Также необходимо быть уверенным, что вы умеет восстанавливать резервные копии, полученные с помощью приложений Exchange для создания резервных копий. Итак, а почему не переписывается промышленная база данных? Очень просто, хранилище информации (Information Store) достаточно умно, чтобы автоматически переправить восстановленную базу данных в RSG. Когда вы создаете RSG, вас также просят указать базу данных для восстановления (смотрите Рисунок 3).
Рисунок 3: Выбор базы данных
Когда вы приступите к восстановлению, Information Store (хранилище информации) проверит, была ли выбрана база данных в RSG. Если она была выбрана, то база данных восстанавливается в RSG, если нет, то процесс восстановления останавливается. Вы также можете увидеть событие с ID 9635 в прикладном журнале событий (application event logs). Источником этой ошибки является MSExchangeIS, а из описания вы поймете, что не найдена база данных.
После удаления RSG, процесс восстановления идет по своему обычному пути. Если вы не хотите удалять RSG, и не хотите восстановить в RSG, то вы можете изменить такое поведение, изменив реестр.
Откройте реестр и найдите параметр
HKLM\System\CurrentControlSet\Services\MSExchangeIS\Parameters\System
Создайте новый параметр типа DWORD под название “Recovery SG Override” и установите его значение в 1. Это позволит вам сохранить RSG, но восстанавливаемая база данных не будет перенаправлена. Я не рекомендую создавать этот ключ в реестре, и если он вам не нужен, то удалите его, после завершения восстановления. Мне кажется, что последнее, что вы захотите – это забыть об этом ключе, а потом долго удивляться, почему старая база данных восстановилась в только что созданную RSG и переписала промышленную базу данных!!!
Откуда RSG узнает, куда восстанавливать почтовый ящик?
После создания RSG и восстановления базы данных, вас, вероятно, заинтересует вопрос, как почтовый ящик из RSG подключается к почтовому ящику в промышленной базе данных. Почтовый ящик в RSG и промышленный почтовый ящик подключаются с помощью следующих двух атрибутов Active Directory
- msExchMailboxGUID
- msExchOrigMDB
Атрибут msExchMailboxGUID уникален для каждого почтового ящика и создается в процессе создания почтового ящика, и затем никогда не изменяется. GUID почтового ящика в RSG должна соответствовать GUID промышленного почтового ящика. Это приводит к общей проблеме с RSG – вы не можете восстановить удаленный почтовый ящик. После удаления почтового ящика, удаляется его GUID, а поэтому при создании нового ящика создается также новый GUID. Т.к. GUID не соответствуют, то нельзя использовать RSG для восстановления данных. На рисунке 4 показана эта связь.
Атрибут msExchOrigMDB позволяет отличить изначальную базу данных от той, в которой был создан почтовый ящик. Благодаря этому атрибуту данные направляются в правильную базу данных. Комбинация атрибута msExchMailboxGUID, который определяет какой почтовый ящик необходимо восстановить, и атрибута msExchOrigMDB, который определяет в какой базе данных находится почтовый ящик, позволяет администратору объединить или скопировать данные в промышленный почтовый ящик (смотрите на рисунке 5).
Это приводит к другой общей проблеме – что случится, если почтовый ящик был перемещен в другую базу данных после того, как была сделана резервная копия? В этом случае атрибут msExchOrigMDB можно отредактировать с помощью ADSIEdit.
Если почтовый ящик был перемещен в другую базу данных, то вы должны отредактировать атрибут msExchOrigMDB в RSG так, чтобы он указывал на базу данных, в которой в настоящий момент содержится почтовый ящик. Для этого откройте редактор ADSIEdit и перейдите к
CN=Configuration,DC=domainname,DC=tld
CN=Services
CN=Microsoft Exchange
CN=ExchangeOrganizationName
CN=Administrative Groups
CN=AdministrativeGroupName
CN=Servers
CN=Servername
CN=InformationStore
CN=StorageGroupName
В этом месте щелкните правой кнопкой мыши на объекте базы данных и выберите Properties (свойства); измените значение для distinguishedName. Затем, найдите параметр RSG database в контейнере CN=Configuration,DC=domainname,DC=tld container. Измените атрибут msExchOrigMDB и введите значение, которое вы вводили ранее. Закройте ADSIEdit и можете восстанавливать ваш перемещенный почтовый ящик.
Заключение
Recovery Storage Groups – это мощный инструмент для администраторов Exchange, который позволяет вам легко восстанавливать данные почтовых ящиков. В этой статье описан принцип их работы, и я надеюсь, что в ней вы найдете ответы на некоторые вопросы по этой тематике.
