Резервное копирование, восстановление и аварийное восстановление в Exchange Server

Статья
04/04/2023

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

Традиционно резервные копии использовались в таких сценариях:

Аварийное восстановление. В случае сбоя оборудования или программного обеспечения несколько копий базы данных в DAG обеспечивают высокий уровень доступности с быстрой отработкой отказа и практически без потери данных. Это позволяет избежать простоя и результирующей потери производительности, что приводит к значительным затратам на восстановление после резервного копирования на прошлый момент времени на диск или ленту. DaG можно расширить на несколько сайтов и обеспечить устойчивость к сбоям диска, сервера, сети и центра обработки данных.
Восстановление случайно удаленных элементов. Исторически сложилось так, что в ситуации, когда пользователь удалял элементы, которые позже требовалось восстановить, он включал поиск резервного носителя, на котором хранились данные, которые необходимо восстановить, а затем каким-то образом получить нужные элементы и предоставить их пользователю. С помощью папки "Элементы с возможностью восстановления" в Exchange 2016 и Exchange 2019 и политики удержания, которая может быть применена к ней, можно хранить все удаленные и измененные данные в течение указанного периода времени, поэтому восстановление этих элементов будет проще и быстрее. Это снижает нагрузку на администраторов Exchange и службу технической поддержки, позволяя конечным пользователям самостоятельно восстанавливать случайно удаленные элементы, тем самым уменьшая сложность и административные расходы, связанные с восстановлением отдельных элементов. Дополнительные сведения см. в разделах Политика обмена сообщениями и соответствие требованиям в Exchange Server и Защита от потери данных в Exchange Server.
Долгосрочное хранение данных. Резервные копии также используются в качестве архива, и обычно лента используется для хранения моментальных снимков данных на определенный момент времени в течение длительных периодов времени в соответствии с требованиями соответствия. Новые функции архивации, поиска по нескольким почтовым ящикам и хранения сообщений в Exchange Server обеспечивают механизм эффективного хранения данных в режиме, доступном конечным пользователям в течение длительных периодов времени. Это позволяет экономить на дорогостоящем восстановлении с ленты и повысить производительность. Дополнительные сведения см. в разделах Архивация на месте в Exchange Server, Обнаружение электронных данных на месте в Exchange Server и Удержание на месте и удержание для судебного разбирательства в Exchange Server.
Моментальный снимок базы данных на определенный момент времени. Если для вашей организации требуется прошедшую копию данных почтового ящика, Exchange предоставляет возможность создать копию базы данных с отстающей базой данных в среде DAG. Это может быть полезно в редких случаях логического повреждения хранилища, реплицируемого на несколько копий баз данных в группе обеспечения доступности баз данных, когда требуется вернуться к определенному моменту времени в прошлом. Также можно использовать эту функцию при случайном удалении администратором почтового ящика или данных пользователя. Восстановление из изолированной копии может выполняться быстрее восстановления из архива, так как изолированные копии не требуют длительного копирования с резервного сервера на сервер Exchange. Это может значительно снизить общую стоимость владения за счет сокращения времени простоя.

Так как существуют собственные функции Exchange Server, которые отвечают каждому из этих сценариев эффективным и экономичным образом, вы можете сократить или исключить использование традиционных резервных копий в вашей среде.

Собственная система защиты данных Exchange

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

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

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

Следует определить, сколько копий базы данных необходимо развернуть. Настоятельно рекомендуется развернуть не менее трех неизолированных копий базы данных почтовых ящиков перед переходом с традиционных форм защиты базы данных, таких как RAID или традиционные архивы на основе VSS.
Необходимо четко определить требования к ожидаемому времени и точке восстановления, а также убедиться, что использование объединенного набора встроенных функций архивации вместо традиционных позволит выполнить эти требования.
Необходимо определить, сколько копий каждой базы данных потребуется создать, чтобы выдержать различные сценарии сбоев, от которых требуется защитить систему.
Следует определить, позволит ли удаление группы обеспечения доступности баз данных или некоторых ее участников выделить необходимые ресурсы для поддержки традиционного решения архивации. Если да, позволит ли это решение улучшить соглашения об уровне обслуживания относительно ожидаемого времени или точки восстановления.
Следует определить, можете ли вы позволить себе потерять моментальную копию, если для участника группы обеспечения доступности баз данных, на котором размещена данная копия, произойдет сбой, влияющий на копию или ее целостность.
Exchange Server позволяет развертывать гораздо большие почтовые ящики с рекомендуемым максимальным размером базы данных почтовых ящиков в 2 ТБ (при использовании двух или более высокодоступных копий баз данных почтовых ящиков). Основываясь на больших почтовых ящиках, которые, скорее всего, будут развернуты большинством организаций, следует определить целевую точку восстановления, если при активации копии базы данных или отстающей копии базы данных необходимо воспроизвести большое количество файлов журналов.
Определите, каким образом будет выполняться обнаружение и предотвращение репликации логического повреждения в активной копии базы данных на пассивные копии этой базы данных. Это включает определение плана восстановления для данной ситуации, а также частоты повторения этого сценария в прошлом. При частых логических повреждениях в организации рекомендуется учитывать этот сценарий при разработке и создать одну или несколько изолированных копий, а также использовать достаточное окно задержки преобразования, позволяющее определить и исправить логическое повреждение до его репликации на другие копии базы данных.

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

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

Чтобы усечение использовалось только на высокодоступных (неизолированных) копиях базы данных почтовых ящиков, следующие вопросы должны иметь положительный ответ.

Архивировался ли файл журнала или включено CRCL.
Файл журнала находится ниже контрольной точки.
Согласны ли другие неотсроченные копии базы данных с удалением.
Изучался ли файл журнала всеми отсроченными копиями базы данных.

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

Файл журнала находится ниже контрольной точки.
Время, прошедшее с момента создания файла журнала, превышает значение ReplayLagTime + TruncationLagTime.
Удаляется ли файл журнала в активной копии базы данных.

Поддерживаемые технологии резервного копирования

Exchange Server поддерживает только резервные копии на основе VSS с поддержкой Exchange. Exchange Server включает подключаемый модуль для резервного копирования Windows Server, который позволяет создавать и восстанавливать резервные копии данных Exchange на основе VSS. Для резервного копирования и восстановления Exchange Server необходимо использовать приложение с поддержкой Exchange, которое поддерживает модуль записи VSS для Exchange Server, например Windows Server Backup (с подключаемым модулем VSS), Microsoft System Center 2012 — Data Protection Manager или стороннее приложение на основе VSS, поддерживающее Exchange.

Дополнительные сведения об архивации и восстановлении данных Exchange с помощью системы архивации данных Windows Server см. в разделе Резервное копирование и восстановление данных Exchange с помощью системы архивации данных Windows Server.

модуль записи VSS Exchange Server

Более ранние версии Exchange включали два средства записи VSS: один внутри службы хранилища сведений Microsoft Exchange (store.exe), а другой — в службе репликации Microsoft Exchange (msexchangerepl.exe). Еще в Exchange 2013 функция записи VSS, ранее обнаруженная в службе Хранилища сведений Microsoft Exchange, была перемещена в службу репликации Microsoft Exchange. Эта архитектура остается неизменной в Exchange 2016 и Exchange 2019. Этот модуль записи с именем Microsoft Exchange Writer используется приложениями на основе VSS с поддержкой Exchange для резервного копирования активных и пассивных копий базы данных, а также для восстановления резервных копий базы данных. Хотя модуль записи выполняется в службе репликации Microsoft Exchange, для объявления записи требуется служба хранилища сведений Microsoft Exchange. В результате для архивации или восстановления баз данных Exchange требуются обе службы.

Восстановление Exchange Server

Почти все параметры конфигурации для серверов почтовых ящиков и служб клиентского доступа хранятся в Active Directory. Как и в предыдущих версиях Exchange, Exchange 2016 и Exchange 2019 включает параметр установки для восстановления потерянных серверов. Этот параметр , /m:RecoverServer, используется для перестроения и повторного создания потерянного сервера с помощью параметров и сведений о конфигурации, хранящихся в Active Directory. Однако обратите внимание, что некоторые параметры не сохраняются, например локальный файл web.config и другие файлы конфигурации. Кроме того, не сохраняются пользовательские записи реестра. Для отслеживания и воссоздания таких изменений мы рекомендуем использовать надежный процесс управления изменениями.

Подробные инструкции по восстановлению сервера с потерянным сервером Exchange см. в разделе Восстановление Exchange Server. Подробные инструкции по восстановлению потерянного сервера, который входит в группу доступности базы данных (DAG), см. в разделе Восстановление сервера-члена группы доступности базы данных.

Восстановление единого хранилища контактов

Если Microsoft Lync Server 2013 или Skype для бизнеса Server 2015 используется в среде Exchange 2016 или Exchange 2019, контактные данные lync/Skype для бизнеса пользователя хранятся в специальной папке контактов в почтовом ящике пользователя. Это называется единым хранилищем контактов (UCS). При восстановлении почтового ящика, перенесенного в UCS, может быть затронут список контактов службы обмена мгновенными сообщениями для конечного пользователя. Если пользователь был перенесен после последней архивации, восстановление почтового ящика приведет к полной потере списка контактов пользователя. В менее значительных случаях изменения списка контактов, внесенные пользователем после последней архивации, будут утеряны. Для устранения риска возможной потери данных убедитесь, что пользователь перенесен на сервер мгновенных сообщений перед восстановлением почтового ящика.

База данных восстановления

База данных восстановления представляет собой специальный тип базы данных почтовых ящиков, который позволяет подключать восстановленную базу данных почтовых ящиков и извлекать данные из восстановленной базы данных в рамках операции восстановления. Для восстановления данных из базы данных восстановления можно использовать командлет New-MailboxRestoreRequest. После извлечения данных их можно экспортировать в папку или добавить в существующий почтовый ящик. Базы данных восстановления позволяют выполнять восстановление данных из архива или копии базы данных без воздействия на пользовательский доступ к текущим данным.

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

Дополнительные сведения см. в разделе Базы данных восстановления. Подробные инструкции по созданию базы данных восстановления см. в разделе Создание базы данных восстановления. Подробные инструкции по использованию базы данных восстановления см. в разделе Восстановление данных с помощью базы данных восстановления.

Переносимость баз данных

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

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

Переносимость аварийного восстановления

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

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

Дополнительные сведения см. в разделе Переносимость звонка. Подробные инструкции по восстановлению абонентского сигнала см. в разделе Восстановление абонентского сигнала.