了解备份、还原和灾难恢复
适用于： Exchange Server 2010 SP2, Exchange Server 2010 SP3
上一次修改主题： 2010-11-01
Microsoft Exchange Server 2010 为高可用性和站点恢复提供了一个统一的新平台，可更快速简单地部署冗余、高可用邮箱数据库。但是，即使是最大限度的冗余和容错也无法防御每一个潜在的故障或灾难。对于所有组织而言，确保对 Exchange 组织中的关键数据提供充分的保护都是一项非常必要的操作任务。
作为数据保护规划的一部分，了解如何保护数据以及确定最适合组织需要的方法十分重要。数据保护规划是一个复杂的过程，它依赖于在部署的规划阶段所做出的很多决策。
目录
支持的备份技术
服务器恢复
恢复数据库
数据库可移植性
拨号音可移植性
Exchange 本机数据保护
支持的备份技术
Microsoft Exchange Server 2007 和 Exchange Server 2003 包括用于数据备份和恢复的两个不同选项：可扩展存储引擎 (ESE) 流式备份 API，并且支持卷影复制服务 (VSS) 备份 API。Exchange 2010 不再支持 ESE 流式 API 用以备份和还原程序文件或数据。而 Exchange 2010 仅支持基于 VSS 的备份。
Exchange 2010 包括一个用于 Windows Server 备份的插件，通过该插件，您可以对 Exchange 数据创建基于 VSS 的备份。可以使用 Windows Server 备份来备份和还原 Exchange 数据库。要备份和还原 Exchange 2010，必须使用支持 Exchange 2010 的 VSS 书写器的 Exchange 感知应用程序，如 Windows Server 备份（带有 VSS 插件）、Microsoft 系统中心数据保护管理器，或基于 VSS 的第三方 Exchange 感知应用程序。使用 VSS 备份和还原 Exchange 数据时，请注意以下限制：
Exchange 2010 附带的 VSS 插件可用于备份包含主动邮箱数据库副本或仅包含独立（非复制）邮箱数据库的卷。无法将其用于备份包含被动邮箱数据库副本的卷。要备份被动邮箱数据库副本，您需要 Microsoft 系统中心数据保护管理器或基于 VSS 的第三方 Exchange 感知应用程序。
被动邮箱数据库副本是通过使用 Microsoft Exchange 复制服务中的独立 VSS 书写器来备份的。Microsoft Exchange 复制服务 VSS 书写器不支持还原。虽然可以使用 Microsoft 系统中心数据保护管理器或基于 VSS 的第三方 Exchange 感知应用程序来备份被动邮箱数据库副本，但是无法直接对被动邮箱数据库副本执行 VSS 还原。不过，您可以在备用位置执行 VSS 还原，挂起被动副本的复制，然后将数据库和日志文件从备用位置复制到文件系统中被动数据库副本的位置。
有关使用 Windows Server 备份来备份和还原 Exchange 数据的详细步骤，请参阅使用 Windows 服务器备份来备份和还原 Exchange 数据。
返回顶部
服务器恢复
几乎所有邮箱、客户端访问、集线器传输和统一消息服务器角色的配置设置都存储在 Active Directory 中。和 Exchange 以前的版本一样，Exchange 2010 也包括用于恢复丢失服务器的安装程序参数。此参数 /m:RecoverServer 用于通过使用存储在 Active Directory 中的设置和配置信息来重建和重新创建丢失服务器。
有关对丢失 Exchange 2010 服务器执行服务器恢复的详细步骤，请参阅恢复 Exchange 服务器。有关对丢失服务器（数据库可用性组成员）执行恢复的详细步骤，请参阅恢复数据库可用性组成员服务器。
返回顶部
恢复数据库
恢复数据库是取代了 Exchange 以前版本中恢复存储组 (RSG) 的一项 Exchange 2010 功能。恢复数据库是一种特殊的邮箱数据库，您可以通过它装入还原的邮箱数据库，并且可以在恢复操作中从还原的数据库提取数据。您可以使用 restore-Mailbox cmdlet 从恢复数据库提取数据。提取后，可将数据导出到一个文件夹或者合并到一个现有邮箱中。恢复数据库使您能够从备份或数据库副本中恢复数据，而不会干扰用户对当前数据的访问。
必须满足一些要求，才可以使用恢复数据库。恢复数据库只能用于 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 功能可以通过有效且具有成本效益的方式满足所有这些需要。
灾难恢复 如果硬件或软件发生故障，数据库可用性组 (DAG) 中的多个数据库副本可通过快速的故障转移实现高可用性，且不会丢失数据。这样可以省去最终用户的停机时间，并且可以避免由于从某个过去时间点备份恢复到磁盘或磁带需要大量成本而导致的生产率降低。DAG 可扩展到多个站点，并且可以针对数据中心故障提供弹性。
意外删除项目的恢复 一直以来，在用户删除了项目但需将其恢复的情况下，都会涉及到查找存储需要恢复的数据的备份媒体，然后以某种方式获取所需项目并将其提供给用户。使用 Exchange 2010 中新的“可恢复项目”文件夹以及适用于此文件夹的保留策略，可在指定的时间段内保留所有删除和修改的数据，因此，恢复这些项目既方便又快捷。这通过帮助最终用户恢复他们自己意外删除的项目来减轻 Exchange 管理员和 IT 技术支持的负担，从而降低了与单个项目恢复相关的复杂程度和管理成本。有关详细信息，请参阅邮件策略和遵从性、了解可恢复的项目和了解保留标记和保留策略。
长期数据存储 有时，也会为存档而进行备份，并且由于受到遵从性要求的约束，通常将磁带用于在更长的一段时间内保留数据的时间点快照。Exchange 2010 中的新存档、多邮箱搜索和邮件保留功能提供了一种机制，可在更长的一段时间内有效地保留数据并使最终用户可以访问。这消除了从磁带恢复的高昂成本，并且通过帮助富客户端（如 Microsoft Outlook 和 Outlook Web App）访问较早的数据来提高最终用户的生产率。有关详细信息，请参阅了解个人存档、了解多邮箱搜索和了解保留标记和保留策略。
时间点数据库快照 如果组织需要邮箱数据的某个过去时间点副本，则 Exchange 可在 DAG 环境中创建滞后副本。此功能对于某种少见事件会有所用处，即逻辑损坏在 DAG 中跨数据库复制，从而导致需要返回到前一时间点。如果管理员意外删除了邮箱或用户数据，此功能也非常有用。从滞后副本恢复可能比从备份还原更快，因为滞后副本不需要从备份服务器到 Exchange 服务器的耗时复制过程。此功能可通过缩短最终用户的停机时间显著降低总拥有成本。
无需备份的日志截断
在成功的完整备份或增量备份结束时所执行的功能之一是截断数据库恢复不再需要的事务日志文件。如果不进行备份，将不会发生日志截断。要防止累积日志文件，请为复制的数据库启用循环日志记录。如果将循环日志记录和连续复制组合使用，即产生被称为连续复制循环日志记录 (CRCL) 的新型循环日志记录，它与 ESE 循环日志记录不同。ESE 循环日志记录由 Microsoft Exchange 信息存储服务执行和管理，而 CRCL 由 Microsoft Exchange 复制服务执行和管理。启用 ESE 循环日志记录时，并不会另外生成日志文件，而会视需要覆盖当前日志文件。但是，在连续复制环境中，需要使用日志文件进行日志传送和重播。因此，启用 CRCL 时，不会覆盖当前的日志文件，并且会生成用于日志传送和传重播过程的已关闭的日志文件。具体而言，Microsoft Exchange 复制服务管理 CRCL 以维持日志连续性，当仍然需要日志以进行复制时，日志删除程序不会删除这些日志。
有关如何启用和禁用循环日志记录的信息，请参阅配置邮箱数据库属性。
实现 Exchange 本机数据保护的注意事项
对于作为传统备份的替代而内置于 Exchange 2010 中的这些功能，在使用之前，您应该考虑一些技术原因和问题。虽然下表并不详尽，但仍然包括了某些注意事项。可能还有特殊的注意事项或特定于组织的注意事项。请考虑以下问题：
将要部署的数据库副本有多少？我们强烈建议在取消对数据库的传统形式的保护（如 RAID 或传统的基于 VSS 的备份）之前，至少应部署三个邮箱数据库副本。
应明确定义您的恢复时间目标和恢复点目标，并且应使用代替传统备份的内置功能组合集将其创建以实现这些目标。
您应该确定每个数据库需要多少个副本，以应对系统将提供保护的各种故障情形。
如果不使用 DAG 或者其部分成员，是否可以获得足够的成本来支持传统的备份解决方案？如果是，则此解决方案是否可以改进恢复时间目标或恢复点目标服务级别协议 (SLA)？
如果托管副本的 DAG 成员发生影响副本或副本完整性的故障，您是否可以承受丢失时间点副本？
Exchange 2010 使您可以部署更大的邮箱，且建议的最大邮箱数据库大小已经从 Exchange 2007 中的 200 GB 增加到了 2 TB（如果使用的邮箱数据库副本为三个或更多）。如果激活数据库副本或滞后数据库副本时必须重播大量的日志记录文件，则基于大多数组织可能会部署的更大邮箱，您的恢复点目标是什么？
您如何检测和防止主动数据库副本中的逻辑损坏复制到被动数据库副本中？对于这种情况，您的恢复规划是什么？以前发生这种情况的频率是多久一次？如果您的组织中经常发生逻辑损坏，我们建议您在设计中考虑此情况时使用一个或多个滞后副本，通过足够的重播延迟窗口，您可以在逻辑损坏已经发生但是尚未复制到其他数据库副本时对其进行检测和处理。
返回顶部
© 2010 Microsoft Corporation。保留所有权利。