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

Область применения: Exchange Server 2013 г.

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

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

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

  • Восстановление случайно удаленных элементов. Исторически, если пользователь удалял элементы, которые позже требовалось восстановить, он включал поиск резервного носителя, на котором хранились данные, которые необходимо восстановить, а затем каким-то образом получить нужные элементы и предоставить их пользователю. Благодаря новой папке "Элементы с возможностью восстановления" в Exchange 2013 и политике удержания, которая может быть применена к ней, можно хранить все удаленные и измененные данные в течение указанного периода времени, поэтому восстановление этих элементов будет проще и быстрее. Это снижает нагрузку на администраторов Exchange и службу технической поддержки, позволяя конечным пользователям самостоятельно восстанавливать случайно удаленные элементы, тем самым уменьшая сложность и административные расходы, связанные с восстановлением отдельных элементов. Дополнительные сведения см. в разделах Политика обмена сообщениями и соответствие требованиям и Защита от потери данных.

  • Долгосрочное хранение данных. Резервные копии также используются в качестве архива, и обычно лента используется для хранения моментальных снимков данных на определенный момент времени в течение длительных периодов времени в соответствии с требованиями соответствия. Новые функции архивации, поиска по нескольким почтовым ящикам и хранения сообщений в Exchange 2013 обеспечивают механизм эффективного хранения данных в режиме доступа конечных пользователей в течение длительных периодов времени. Это позволяет экономить на дорогостоящем восстановлении с ленты и повысить производительность. Дополнительные сведения см. в разделах Архивация на месте в Exchange 2013, Обнаружение электронных данных на месте и Удержание на месте и удержание для судебного разбирательства.

  • Моментальный снимок базы данных на определенный момент времени. Если для вашей организации требуется прошедшую копию данных почтового ящика, Exchange предоставляет возможность создать копию базы данных с отстающей базой данных в среде DAG. Это может быть полезно в редких случаях логического повреждения хранилища, реплицируемого на несколько копий баз данных в группе обеспечения доступности баз данных, когда требуется вернуться к определенному моменту времени в прошлом. Также можно использовать эту функцию при случайном удалении администратором почтового ящика или данных пользователя. Восстановление из изолированной копии может выполняться быстрее восстановления из архива, так как изолированные копии не требуют длительного копирования с резервного сервера на сервер Exchange. Это может значительно снизить общую стоимость владения за счет сокращения времени простоя.

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

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

Supported Backup Technologies

Exchange 2013 VSS Writer

Server Recovery

Unified Contact Store Recovery

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

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

Dial Tone Portability

Собственная система защиты данных 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, автоматически перенаправляются на новый сервер без необходимости вручную обновлять профиль настольной системы пользователя. После восстановления данных исходного почтового ящика пользователя администратор может объединить восстановленный и аварийный почтовые ящики пользователя в один обновленный почтовый ящик.

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

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