Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Область применения: Exchange Server 2013
При планировании защиты данных необходимо иметь представление о способах защиты данных и определить способы, которые бы соответствовали требованиям организации. Планирование защиты данных это сложный процесс, основанный на многочисленных решениях, принимаемых на этапе планирования развертывания.
Традиционно резервные копии использовались в таких сценариях:
Аварийное восстановление: в случае аппаратного или программного сбоя несколько копий баз данных в группе обеспечения доступности баз данных обеспечивают высокую доступность с быстрой отработкой отказа и минимальной потерей данных или вообще без них. Это устраняет простои и, как следствие, потерю производительности, что влечет за собой значительные затраты на восстановление из прошлого резервного копирования на определенный момент времени на диск или ленту. Группы обеспечения доступности баз данных могут быть расширены до нескольких сайтов и могут обеспечивать устойчивость к сбоям дисков, серверов, сети и центров обработки данных.
Восстановление случайно удаленных элементов: Исторически, если пользователь удалял элементы, которые позже необходимо было восстановить, это включало в себя поиск носителя резервной копии, на котором хранились данные, которые необходимо было восстановить, а затем каким-то образом получение желаемых элементов и предоставление их пользователю. С помощью новой папки "Восстанавливаемые элементы" в Exchange 2013 и политики удержания, которую можно применить к ней, можно хранить все удаленные и измененные данные в течение определенного периода времени, поэтому восстановление этих элементов становится проще и быстрее. Это снижает нагрузку на администраторов Exchange и службу технической поддержки, позволяя конечным пользователям самостоятельно восстанавливать случайно удаленные элементы, тем самым снижая сложность и административные расходы, связанные с восстановлением одного элемента. Дополнительные сведения см. в статьях "Политика обмена сообщениями и соответствие требованиям " и "Защита от потери данных".
Долгосрочное хранение данных: резервные копии также используются в качестве архива, и, как правило, лента используется для сохранения моментальных снимков данных на определенный момент времени в течение длительных периодов времени в соответствии с нормативными требованиями. Новые функции архивации, поиска в нескольких почтовых ящиках и хранения сообщений в Exchange 2013 предоставляют механизм для эффективного хранения данных в доступной для конечного пользователя форме в течение длительных периодов времени. Это позволяет экономить на дорогостоящем восстановлении с ленты и повысить производительность. Дополнительные сведения см. в статьях Архивация на месте в Exchange 2013, Обнаружение электронных данных на месте, а также Удержание на месте и Удержание для судебного разбирательства.
База данных на определенный момент времени snapshot: если для организации требуется предыдущая копия данных почтового ящика на определенный момент времени, Exchange предоставляет возможность создать отложенную копию базы данных в среде группы обеспечения доступности баз данных. Это может быть полезно в редких случаях логического повреждения хранилища, реплицируемого на несколько копий баз данных в группе обеспечения доступности баз данных, когда требуется вернуться к определенному моменту времени в прошлом. Также можно использовать эту функцию при случайном удалении администратором почтового ящика или данных пользователя. Восстановление из изолированной копии может выполняться быстрее восстановления из архива, так как изолированные копии не требуют длительного копирования с резервного сервера на сервер Exchange. Это может значительно снизить общую стоимость владения за счет сокращения времени простоя.
Поскольку в Exchange 2013 есть собственные функции, которые эффективно и экономично соответствуют каждому из этих сценариев, вы сможете реже использовать традиционные резервные копии в своей среде или полностью отказаться от них.
Собственная система защиты данных Exchange
Unified Contact Store Recovery
Собственная система защиты данных Exchange
В предпочтительной архитектуре Майкрософт для Exchange Server 2013 используется принцип собственной системы защиты данных Exchange. Собственная система защиты данных Exchange основана на встроенных функциях Exchange для защиты данных почтового ящика без использования резервных копий (хотя эти функции можно использовать и для создания резервных копий). Exchange 2013 включает несколько новых функций и существенных изменений, которые в случае правильного развертывания и настройки могут обеспечить собственную систему защиты данных и ограничить необходимость использования традиционного резервного копирования. Использование функций высокой доступности, встроенных в Exchange 2013, для минимизации простоев и потери данных в случае аварии, также может снизить совокупную стоимость владения системой обмена сообщениями. В сочетании с другими встроенными функциями, такими как удержание по юридическим причинам, эти функции могут помочь вам уменьшить или исключить использование традиционного резервного копирования на определенный момент времени, а также сэкономить на сопутствующих расходах.
Кроме определения преимуществ возможного ухода от традиционной архивации, которые предоставляет система Exchange 2013, также рекомендуется оценить расходы на текущую инфраструктуру архивации. Рассчитайте затраты, связанные с простоями и потерями данных для конечных пользователей при попытке восстановления после сбоя с помощью такой инфраструктуры. Следует также учитывать расходы на оборудование, установку и покупку лицензии, а также расходы на управление, связанные с восстановлением данных и обслуживанием архивов. В зависимости от требований вашей организации вполне вероятно, что чистая среда Exchange 2013 по крайней мере с тремя копиями базы данных почтовых ящиков обеспечит меньшую совокупную стоимость владения, чем среда с резервными копиями.
Существуют ли некоторые проблемы, которые необходимо учитывать при использовании встроенных функций Exchange 2013, заменяющих традиционные функции архивации. Кроме того, возможны соображения, уникальные для вашей организации. Рассмотрите следующие вопросы и обратите внимание, что этот список не является исчерпывающим.
Следует определить, сколько копий базы данных необходимо развернуть. Настоятельно рекомендуется развернуть не менее трех неизолированных копий базы данных почтовых ящиков перед переходом с традиционных форм защиты базы данных, таких как RAID или традиционные архивы на основе VSS.
Необходимо четко определить целевое время восстановления и целевую точку восстановления, а также установить, что для достижения этих целей следует использовать комбинированный набор встроенных функций вместо традиционных резервных копий.
Необходимо определить, сколько копий каждой базы данных необходимо для защиты от различных сценариев сбоев, на случай которых предназначена ваша система.
Следует определить, позволит ли удаление группы обеспечения доступности баз данных или некоторых ее участников выделить необходимые ресурсы для поддержки традиционного решения архивации. Если да, позволит ли это решение улучшить соглашения об уровне обслуживания относительно ожидаемого времени или точки восстановления.
Следует определить, можете ли вы позволить себе потерять моментальную копию, если для участника группы обеспечения доступности баз данных, на котором размещена данная копия, произойдет сбой, влияющий на копию или ее целостность.
Exchange 2013 позволяет развертывать гораздо более крупные почтовые ящики с рекомендуемым максимальным размером базы данных почтовых ящиков в 2 терабайта (если используются две или более высокодоступные копии базы данных почтовых ящиков). С учетом крупных почтовых ящиков, которые большинство организаций скорее всего разместят, следует определить целевую точку восстановления, если вам необходимо воспроизвести большое количество файлов журнала при активации копии базы данных или отложенной копии базы данных.
Определите, каким образом будет выполняться обнаружение и предотвращение репликации логического повреждения в активной копии базы данных на пассивные копии этой базы данных. Это включает определение плана восстановления для данной ситуации, а также частоты повторения этого сценария в прошлом. При частых логических повреждениях в организации рекомендуется учитывать этот сценарий при разработке и создать одну или несколько изолированных копий, а также использовать достаточное окно задержки преобразования, позволяющее определить и исправить логическое повреждение до его репликации на другие копии базы данных.
При успешном завершении полной или добавочной архивации осуществляется усечение файлов журнала транзакций, которые больше не требуются для восстановления базы данных. Если резервные копии не создаются, усечение журнала не выполняется. Чтобы предотвратить создание большого количества файлов журнала, необходимо включить циклическое ведение журнала для реплицированных баз данных. Использование циклического ведения журнала с непрерывной репликацией является новым типом циклического ведения журнала, который называется циклическим ведением журнала непрерывной репликации (CRCL) и отличается от циклического ведения журнала расширенного обработчика хранилищ. В то время как циклическое ведение журнала расширенного обработчика хранилищ выполняется и управляется службой банка данных Microsoft Exchange, циклическое ведение журнала непрерывной репликации выполняется и управляется службой репликации Microsoft Exchange. При включенном циклическом ведении журнала расширенного обработчика хранилищ дополнительные файлы журнала не создаются; вместо этого при необходимости перезаписывается текущий файл журнала. Однако в среде с непрерывной репликацией файлы журнала необходимы для доставки и преобразования журналов. В результате при включении циклического ведения журнала непрерывной репликации текущий файл журнала не перезаписывается, а для процесса доставки и преобразования журналов создаются закрытые файлы журнала.
В частности, служба репликации Microsoft Exchange управляет процессом циклического ведения журнала непрерывной репликации таким образом, что обеспечивается непрерывность журналов, а журналы не удаляются, пока они необходимы для репликации. Служба репликации Microsoft Exchange и служба банка данных Microsoft Exchange взаимодействуют с помощью удаленного вызова процедур (RPC), касающихся того, какие файлы журнала могут быть удалены.
Чтобы усечение использовалось только на высокодоступных (неизолированных) копиях базы данных почтовых ящиков, следующие вопросы должны иметь положительный ответ.
- Архивировался ли файл журнала или включено CRCL.
- Файл журнала находится ниже контрольной точки.
- Согласны ли другие неотсроченные копии базы данных с удалением.
- Изучался ли файл журнала всеми отсроченными копиями базы данных.
Чтобы усечение использовалось только на изолированных копиях базы данных, следующие вопросы должны иметь положительный ответ.
- Файл журнала находится ниже контрольной точки.
- Время, прошедшее с момента создания файла журнала, превышает значение ReplayLagTime + TruncationLagTime.
- Удаляется ли файл журнала в активной копии базы данных.
Поддерживаемые технологии резервного копирования
Exchange 2013 поддерживает только резервное копирование на основе VSS с поддержкой Exchange. Exchange 2013 содержит подключаемый модуль системы архивации данных Windows Server, который позволяет создавать и восстанавливать резервные копии данных Exchange на основе VSS. Чтобы выполнить архивацию и восстановление сервера Exchange 2013, необходимо использовать приложение Exchange, поддерживающее модуль записи VSS для Exchange 2013, например систему архивации данных Windows Server (с подключаемым модулем VSS), Microsoft System Center 2012 Data Protection Manager или стороннее приложение Exchange на основе VSS.
Дополнительные сведения об архивации и восстановлении данных Exchange с помощью системы архивации данных Windows Server см. в разделе Резервное копирование и восстановление данных Exchange с помощью системы архивации данных Windows Server.
Модуль записи VSS Exchange 2013
В Exchange 2013 представлены значительные изменения архитектуры модуля записи VSS, используемой в Exchange 2010 и Exchange 2007. Эти более ранние версии Exchange содержали два модуля записи VSS: один в службе банка данных Microsoft Exchange (store.exe) и один в службе репликации Microsoft Exchange Replication (msexchangerepl.exe). В Exchange функции модуля записи VSS, ранее доступные в службе банка данных Microsoft Exchange, были перемещены в службу репликации Microsoft Exchange. Новый модуль записи, Microsoft Exchange Writer, теперь используется приложениями Exchange на основе VSS для архивации активных и пассивных копий баз данных, а также для восстановления архивированных копий баз данных. Хотя новый модуль записи выполняется в службе репликации Microsoft Exchange, для объявления данных о нем требуется запуск службы банка данных Microsoft Exchange. В результате для архивации или восстановления баз данных Exchange требуются обе службы.
Восстановление Exchange Server
Почти все параметры конфигурации для серверов почтовых ящиков и клиентского доступа хранятся в Active Directory. Как и предыдущие версии Exchange, Exchange 2013 включает в себя параметр установки для восстановления потерянных серверов. Этот параметр /m:RecoverServer используется для восстановления и повторного создания потерянного сервера с использованием параметров и сведений о конфигурации, хранящихся в Active Directory. Однако обратите внимание, что некоторые параметры не сохраняются, например локальный файл web.config и другие файлы конфигурации. Кроме того, не сохраняются пользовательские записи реестра. Для отслеживания и воссоздания таких изменений мы рекомендуем использовать надежный процесс управления изменениями.
Подробные инструкции по восстановлению потерянного сервера Exchange 2013 см. в статье Восстановление сервера Exchange Server. Подробные инструкции по восстановлению потерянного сервера, который является членом группы доступности баз данных (DAG), см. в статье Восстановление сервера, входящего в группу доступности базы данных.
Восстановление единого хранилища контактов
При использовании Lync 2013 в среде Exchange 2013 контактные данные пользователя Lync хранятся в специальной папке контактов в почтовом ящике пользователя. Это называется единым хранилищем контактов (UCS). При восстановлении почтового ящика, перенесенного в UCS, может быть затронут список контактов службы обмена мгновенными сообщениями для конечного пользователя. Если пользователь был перенесен после последней архивации, восстановление почтового ящика приведет к полной потере списка контактов пользователя. В менее значительных случаях изменения списка контактов, внесенные пользователем после последней архивации, будут утеряны. Для устранения риска возможной потери данных убедитесь, что пользователь перенесен на сервер мгновенных сообщений перед восстановлением почтового ящика.
База данных восстановления
База данных восстановления представляет собой специальный тип базы данных почтовых ящиков, который позволяет подключать восстановленную базу данных почтовых ящиков и извлекать данные из восстановленной базы данных в рамках операции восстановления. Для восстановления данных из базы данных восстановления можно использовать командлет New-MailboxRestoreRequest. После извлечения данных их можно экспортировать в папку или добавить в существующий почтовый ящик. Базы данных восстановления позволяют выполнять восстановление данных из архива или копии базы данных без воздействия на пользовательский доступ к текущим данным.
Использование базы данных восстановления для базы данных почтовых ящиков из предыдущих версий Exchange не поддерживается. Кроме того, целевой почтовый ящик, используемый для слияния и извлечения данных, должен находиться в том же лесу Active Directory, что и база данных, подключенная в базе данных восстановления.
Дополнительные сведения см. в статье "Базы данных восстановления". Подробные инструкции по созданию базы данных восстановления см. в статье Создание базы данных восстановления. Подробные инструкции по использованию базы данных восстановления см. в статье "Восстановление данных с помощью базы данных восстановления".
Переносимость баз данных
Переносимость баз данных это функция, позволяющая перемещать базу данных почтовых ящиков Exchange 2013 на любой другой сервер почтовых ящиков Exchange 2013 в той же организации и подключать ее на этом сервере. Использование переносимости баз данных повышает надежность благодаря устранению шагов, выполняемых вручную, когда высока вероятность возникновения ошибки, из процедур аварийного восстановления. Переносимость баз данных также позволяет сократить общее время восстановления для различных сценариев сбоя.
Дополнительные сведения см. в статье Переносимость базы данных. Подробные инструкции по использованию переносимости базы данных см. в статье Перемещение базы данных почтовых ящиков с использованием переносимости базы данных.
Переносимость аварийного восстановления
Переносимость аварийного восстановления — это функция, обеспечивающая решение для ограниченной поддержки непрерывной работы электронной почты в случае ошибок, влияющих на базу данных почтовых ящиков, сервер или весь сайт. Переносимость аварийного восстановления предоставляет пользователю временный почтовый ящик для отправки и получения электронной почты на время восстановления или исправления его исходного почтового ящика. Временный почтовый ящик может находиться на том же сервере почтовых ящиков Exchange 2013 или на любом другом сервере почтовых ящиков Exchange 2013 в организации. Это позволяет разместить на альтернативном сервере почтовые ящики пользователей, находившиеся на сервере, который стал недоступен. Клиенты, поддерживающие функцию автообнаружения, например Microsoft Outlook, автоматически перенаправляются на новый сервер без необходимости вручную обновлять профиль настольной системы пользователя. После восстановления данных исходного почтового ящика пользователя администратор может объединить восстановленный и аварийный почтовые ящики пользователя в один обновленный почтовый ящик.
Процесс использования переносимости аварийного восстановления называется аварийным восстановлением. Аварийное восстановление включает в себя создание на сервере почтовых ящиков пустой базы данных вместо неисправной. Эта пустая база данных, которая называется аварийной базой данных, позволяет пользователям отправлять и получать электронную почту, пока неисправная база данных восстанавливается. После восстановления неисправной базы данных аварийная и восстановленная базы данных переключаются, а данные аварийной базы данных добавляются в восстановленную базу данных.
Дополнительные сведения см. в разделе Переносимость тонального сигнала. Подробные инструкции по выполнению восстановления тонального сигнала см. в разделе "Выполнение восстановления тонального сигнала".