Применимо к: Exchange Server 2010 SP1
Последнее изменение раздела: 2010-11-01
Система Microsoft Exchange Server 2010 основана на новой единой платформе, обеспечивающей высокий уровень доступности и устойчивость сайтов, упрощающей и ускоряющей развертывание избыточных баз данных почтовых ящиков высокой доступности. Но даже предельные формы избыточности и отказоустойчивости не могут защитить систему от всех возможных ошибок или сбоев. Обеспечение надежной защиты критических данных в организации Exchange является важной эксплуатационной задачей для всех организаций.
При планировании защиты данных необходимо иметь представление о способах защиты данных и определить такие способы, которые бы соответствовали требованиям организации. Планирование защиты данных — это сложный процесс, основанный на многочисленных решениях, принимаемых на этапе планирования развертывания.
Содержание
Поддерживаемые технологии архивации
Переносимость аварийного восстановления
Собственная система защиты данных Exchange
Поддерживаемые технологии архивации
Microsoft Exchange Server 2007 и Exchange Server 2003 включают в себя две технологии архивации и восстановления данных: интерфейсы API потоковых архивов расширенного обработчика хранилищ (ESE) и поддержку интерфейсов API архивов службы теневого копирования томов (VSS). Exchange 2010 не поддерживает потоковые интерфейсы API расширенного обработчика хранилищ для архивации и восстановления программных файлов и данных. Exchange 2010 поддерживает только архивы на основе VSS.
Exchange 2010 включает в себя подключаемый модуль системы архивации данных Windows Server, который позволяет выполнять архивацию данных Exchange на основе службы теневого копирования томов (VSS). Систему архивации данных Windows Server можно использовать для архивации и восстановления баз данных Exchange. Чтобы выполнить архивацию и восстановление сервера Exchange 2010, необходимо использовать приложение Exchange, поддерживающее модуль записи VSS для Exchange 2010, например систему архивации данных Windows Server (с подключаемым модулем VSS), Microsoft System Center Data Protection Manager или стороннее приложение Exchange на основе VSS. При использовании службы теневого копирования томов для архивации и восстановления данных Exchange необходимо учитывать следующие ограничения.
- Подключаемый модуль VSS, поставляемый с Exchange 2010, можно
использовать для архивации томов, содержащих активные копии базы
данных почтовых ящиков или только автономные (нереплицированные)
базы данных почтовых ящиков. Его невозможно использовать для
архивации томов, содержащих пассивные копии базы данных почтовых
ящиков. Чтобы выполнить архивацию пассивных копий базы данных
почтовых ящиков, необходимо использовать Microsoft System Center
Data Protection Manager или стороннее приложение Exchange на основе
VSS.
- Пассивные копии базы данных почтовых ящиков архивируются с
помощью отдельного модуля записи VSS в службе репликации Microsoft
Exchange. Модуль записи VSS службы репликации Microsoft Exchange не
поддерживает восстановление. Архивировать пассивные копии базы
данных почтовых ящиков можно с помощью Microsoft System Center Data
Protection Manager или стороннего приложения Exchange на основе
VSS, но невозможно выполнить восстановление VSS непосредственно в
пассивную копию базы данных почтовых ящиков. Тем не менее,
можно выполнить восстановление VSS в другое расположение,
приостановить репликацию пассивной копии, а затем скопировать базу
данных и файлы журнала из этого расположения в расположение
пассивной копии базы данных в файловой системе.
Дополнительные сведения об архивации и восстановлении данных Exchange с помощью системы архивации данных Windows Server см. в разделе Создание резервной копии данных Exchange и их восстановление с помощью системы архивации данных Windows Server.
Восстановление сервера
Практически все параметры конфигурации для ролей сервера почтовых ящиков, сервера клиентского доступа, транспортного сервера-концентратора и сервера единой системы обмена сообщениями хранятся в службах каталогов Служба каталогов Active Directory. Как и предыдущие версии Exchange, Exchange 2010 включает в себя параметр установки для восстановления потерянных серверов. Этот параметр, /m:RecoverServer, используется для перестроения и повторного создания потерянного сервера с помощью параметров конфигурации и сведений о конфигурации, хранящихся в Служба каталогов Active Directory.
Дополнительные сведения о восстановлении потерянного сервера Exchange 2010 см. в разделе Восстановление сервера Exchange. Дополнительные сведения о восстановлении потерянного сервера, являющегося участником группы доступности баз данных, см. в разделе Восстановление рядового сервера группы обеспечения доступности баз данных.
Восстановление базы данных
База данных восстановления — это функция Exchange 2010, заменяющая группу хранения для восстановления (RSG) в предыдущих версиях Exchange. База данных восстановления представляет собой специальный тип базы данных почтовых ящиков, который позволяет подключать восстановленную базу данных почтовых ящиков и извлекать данные из восстановленной базы данных в рамках операции восстановления. Для восстановления данных из базы данных восстановления можно использовать командлет Restore-Mailbox. После извлечения данных их можно экспортировать в папку или добавить в существующий почтовый ящик. Базы данных восстановления позволяют выполнять восстановление данных из архива или копии базы данных без воздействия на пользовательский доступ к текущим данным.
Чтобы использовать базу данных восстановления, необходимо выполнить определенные требования. Базу данных восстановления можно использовать только для баз данных почтовых ящиков Exchange 2010. Базы данных почтовых ящиков предыдущих версий Exchange не поддерживаются. Кроме того, целевой почтовый ящик, используемый для слияния и извлечения данных, должен находиться в том же лесу Служба каталогов Active Directory, что и база данных, подключенная в базе данных восстановления.
Дополнительные сведения см. в разделе Базы данных восстановления. Дополнительные сведения о создании базы данных восстановления см. в разделе Создание базы данных восстановления. Дополнительные сведения об использовании базы данных восстановления см. в разделе Восстановление данных с помощью базы данных восстановления.
Переносимость баз данных
Переносимость баз данных — это функция, позволяющая перемещать базу данных почтовых ящиков Exchange 2010 на любой другой сервер почтовых ящиков Exchange 2010 в той же организации и подключать ее на этом сервере. Использование переносимости баз данных повышает надежность благодаря устранению ручных этапов, которые отличаются высокой вероятностью возникновения ошибки, из процедур восстановления. Переносимость баз данных также позволяет сократить общее время восстановления для различных сценариев сбоя.
Дополнительные сведения см. в разделе Переносимость баз данных. Дополнительные сведения об использовании переносимости баз данных см. в разделе Перемещение базы данных почтовых ящиков с помощью функции переносимости базы данных.
Переносимость аварийного восстановления
Переносимость аварийного восстановления — это функция, обеспечивающая решение для ограниченной поддержки непрерывной работы электронной почты в случае ошибок, влияющих на базу данных почтовых ящиков, сервер или весь сайт. Переносимость аварийного восстановления предоставляет пользователю временный почтовый ящик для отправки и получения электронной почты на время восстановления или исправления его исходного почтового ящика. Временный почтовый ящик может находиться на том же сервере почтовых ящиков Exchange 2010 или на любом другом сервере почтовых ящиков Exchange 2010 в организации. Это позволяет разместить на альтернативном сервере почтовые ящики пользователей, находившиеся на сервере, который стал недоступен. Клиенты, поддерживающие функцию автообнаружения, например Microsoft Outlook 2010 или Office Outlook 2007, автоматически перенаправляются на новый сервер без необходимости вручную обновлять профиль рабочего стола пользователя. После восстановления данных исходного почтового ящика пользователя администратор может объединить восстановленный и аварийный почтовые ящики пользователя в один обновленный почтовый ящик.
Процесс использования переносимости аварийного восстановления называется аварийным восстановлением. Аварийное восстановление включает в себя создание на сервере почтовых ящиков пустой базы данных вместо неисправной базы данных. Эта пустая база данных, называемая аварийной базой данных, позволяет пользователям отправлять и получать электронную почту, пока неисправная база данных восстанавливается. После восстановления неисправной базы данных аварийная и восстановленная базы данных переключаются, а данные аварийной базы данных добавляются в восстановленную базу данных.
Дополнительные сведения см. в разделе Переносимость аварийного восстановления. Дополнительные сведения об аварийном восстановлении см. в разделе Выполнение восстановления тонового набора.
Собственная система защиты данных Exchange
Сервер Exchange 2010 содержит несколько новых функций и ключевых улучшений, которые при правильном развертывании и настройке обеспечивают собственную защиту данных без необходимости выполнения традиционной архивации данных. Встроенные в Exchange 2010 функции высокой доступности, предназначенные для минимизации времени простоев и потерь данных в случае сбоя, также позволяют снизить общую стоимость владения системой обмена сообщениями. В сочетании с другими встроенными функциями, такими как юридическое удержание, эти функции могут помочь организациям уменьшить или исключить зависимость от традиционной архивации на определенный момент времени, а также сэкономить на сопутствующих расходах.
Кроме определения преимуществ возможного ухода от традиционной архивации, которые предоставляет система Exchange 2010, также рекомендуется оценить расходы на текущую инфраструктуру архивации. Рассчитайте затраты, связанные с простоями и потерями данных для конечных пользователей при попытке восстановления после сбоя с помощью такой инфраструктуры. Следует также учитывать расходы на оборудование, установку и покупку лицензии, а также расходы на управление, связанные с восстановлением данных и обслуживанием архивов. В зависимости от требований организации велика вероятность того, что общая стоимость владения чистой средой Exchange 2010 как минимум с тремя копиями базы данных почтовых ящиков будет ниже, чем у среды с архивами.
Архивы обычно используются в следующих сценариях, а также существуют функции Exchange 2010, позволяющие выполнить текущие требования организации эффективным и экономичным способом.
- Аварийное восстановление При
возникновении сбоя оборудования или программного обеспечения для
нескольких копий базы данных в группе доступности баз данных
включается высокая доступность с быстрой обработкой отказа без
потери данных. Это исключает простои для конечных пользователей и
снижение производительности, что является значительным
преимуществом восстановления по сравнению с архивацией на
определенный момент времени, выполняемой на диск или ленту. Группы
доступности баз данных можно расширить на несколько сайтов; они
обеспечивают устойчивость к сбоям в центре данных.
- Восстановление случайно удаленных
элементов Раньше, в случае удаления
пользователем элементов, которые необходимо было восстановить,
требовалось найти резервный носитель, на котором хранились
восстанавливаемые данные, а затем извлечь эти данные и предоставить
их пользователю. Благодаря папке «Элементы для восстановления» в
Exchange 2010 и политике удержания, применяемой к этой папке, можно
сохранять все удаленные и измененные данные в течение определенного
времени, что позволяет упростить и ускорить процесс восстановления
данных. В результате можно сократить накладные расходы за счет
сокращения количества администраторов и специалистов службы
ИТ-поддержки Exchange и предоставления конечным пользователям
возможности самостоятельно восстанавливать случайно удаленные
элементы. Функция восстановления случайно удаленных элементов также
позволяет упростить инфраструктуру и сократить затраты на
администрирование, связанные с восстановлением одного элемента.
Дополнительные сведения см. в разделах Политика обмена
сообщениями и соответствие требованиям, Общие сведения об
элементах для восстановления и Общие сведения о тегах и
политиках хранения.
- Долговременное хранение данных Иногда
функцию архивов выполняют резервные копии, и при этом обычно
используется лента для сохранения моментальных снимков данных в
течение длительного периода времени, определенного регулятивными
требованиями. Новая система архивации данных, функции поиска в
нескольких почтовых ящиках и хранения сообщений в Exchange 2010
предоставляют механизм эффективного хранения данных в течение
длительного периода времени с возможностью доступа конечных
пользователей к этим данным. Это позволяет экономить на
дорогостоящем восстановлении с ленты и повысить производительность
работы конечных пользователей за счет предоставления клиентам,
таким как Microsoft Outlook и Outlook Web App, доступа к старым
данным. Дополнительные сведения см. в разделах Общие сведения о личных
архивах, Общие сведения о поиске
по нескольким почтовым ящикам и Общие сведения о тегах и
политиках хранения.
- Моментальный снимок базы данных Если в
организации требуется копирование данных почтового ящика на
определенный момент времени, можно использовать в Exchange функцию
создания изолированных копий в среде группы доступности баз данных.
Это может быть полезно в редких случаях логического повреждения,
реплицируемого на базы данных в группе доступности баз данных,
когда требуется вернуться к определенному моменту времени в
прошлом. Также можно использовать эту функцию при случайном
удалении администратором почтового ящика или данных пользователя.
Восстановление из изолированной копии может выполняться быстрее
восстановления из архива, так как изолированные копии не требуют
длительного копирования с резервного сервера на сервер Exchange.
Это может значительно снизить общую стоимость владения за счет
сокращения времени простоя для конечных пользователей.
Усечение журнала без архивов
Одной из функций, выполняемых при успешном завершении полной или добавочной архивации, является усечение файлов журнала транзакций, которые больше не требуются для восстановления базы данных. Если архивы не используются, усечение журнала не выполняется. Чтобы предотвратить создание большого количества файлов журнала, необходимо включить циклическое ведение журнала для реплицированных баз данных. Использование циклического ведения журнала с непрерывной репликацией является новым типом циклического ведения журнала, который называется циклическим ведением журнала непрерывной репликации (CRCL) и отличается от циклического ведения журнала расширенного обработчика хранилищ. В то время как циклическое ведение журнала расширенного обработчика хранилищ выполняется и управляется службой банка данных Microsoft Exchange, циклическое ведение журнала непрерывной репликации выполняется и управляется службой репликации Microsoft Exchange. При включении циклического ведения журнала расширенного обработчика хранилищ дополнительные файлы журнала не создаются; вместо этого текущий файл журнала перезаписывается при необходимости. Однако в среде с непрерывной репликацией файлы журнала необходимы для доставки и преобразования журналов. В результате при включении циклического ведения журнала непрерывной репликации текущий файл журнала не перезаписывается, а для процесса доставки и преобразования журналов создаются закрытые файлы журнала. В частности, служба репликации Microsoft Exchange управляет процессом циклического ведения журнала непрерывной репликации таким образом, что обеспечивается непрерывность журналов, а журналы не удаляются, пока они необходимы для репликации.
Дополнительные сведения о включении и отключении циклического ведения журнала см. в разделе Настройка свойств базы данных почтовых ящиков.
Особенности внедрения собственной системы защиты данных Exchange
Существуют некоторые требования технического характера и некоторые проблемы, которые необходимо учитывать при использовании встроенных функций Exchange 2010, заменяющих традиционные функции архивации. В следующем списке приведены некоторые особенности использования этих функций (список не является полным). Также могут существовать специальные, уникальные рекомендации для определенной организации. Рассмотрите следующие вопросы.
- Сколько копий базы данных будет развернуто? Рекомендуется
развернуть не менее трех копий базы данных почтовых ящиков перед
переходом с традиционных форм защиты базы данных, таких как RAID
или традиционные архивы на основе VSS.
- Необходимо четко определить требования к ожидаемому времени
восстановления и сроку выполнения восстановления, а также
убедиться, что использование объединенного набора встроенных
функций архивации вместо традиционных позволит выполнить эти
требования.
- Необходимо определить, сколько копий каждой базы данных
потребуется создать, чтобы выдержать различные сценарии сбоев, от
которых требуется защитить систему.
- Позволит ли удаление группы доступности баз данных или
некоторых ее участников выделить необходимые ресурсы для поддержки
традиционного решения архивации? Если да, то позволит ли это
решение улучшить соглашения об условиях обслуживания ожидаемого
времени восстановления и срока выполнения восстановления?
- Можете ли вы позволить себе потерять моментальную копию, если
для участника группы доступности баз данных, на котором расположена
эта копия, произойдет сбой, влияющий на копию или целостность
копии?
- Exchange 2010 позволяет развертывать большие почтовые ящики.
Рекомендуемый максимальный размер базы данных почтовых ящиков
увеличен с 200 ГБ в Exchange 2007 до 2 ТБ (при
использовании трех или более копий базы данных почтовых ящиков). С
учетом больших почтовых ящиков, которые обычно развертывают
организации, каков будет срок выполнения восстановления, если
требуется преобразовать большое количество файлов журнала при
активации копии базы данных или изолированной копии базы
данных?
- Каким образом будет выполняться обнаружение и предотвращение
репликации логического повреждения в активной копии базы данных на
пассивные копии этой базы данных? Какой вариант восстановления
будет выбран в этом случае? Как часто этот сценарий происходил в
прошлом? При частых логических повреждениях в организации
рекомендуется учитывать этот сценарий при разработке и создать одну
или несколько изолированных копий, а также использовать достаточное
окно задержки преобразования, позволяющее определить и исправить
логическое повреждение до его репликации на другие копии базы
данных.