Microsoft Exchange Server 的设计考虑了备份因素。组织需要备份其邮件数据，同时还必须能够恢复这些信息。为满足这些要求，Microsoft 构建了一整套数据保护选项，从传统的备份和低端的恢复到操作连续性，直至可提供最高水平的可用性和灾难恢复功能的真正业务连续性解决方案。在本文中，我将介绍这些选项并帮助您决定如何为您的组织实施最佳 Exchange 恢复解决方案。

　　级别 1：基本备份和恢复

　　您可以在数据库脱机后备份 Exchange 文件，也可以在数据库正在运行时进行备份。实际上，更多情况下建议采用后一种方式来备份 Exchange。但 Exchange 不仅仅是一组文件。它是包含大型数据库文件和事务日志的信息存储区。发送给 Exchange 的邮件消息会立即记录在事务日志中，当系统进入某些空闲周期时(通常在若干毫秒之后)，这些消息将复制到数据库中。Exchange 通过将信息尽快存储到磁盘，来提供高水平的恢复功能。恢复 Exchange 最根本的是这两组信息的可用性。一旦系统出现故障，则需要结合使用上一次备份以及该备份点之后发生的所有事务，将 Exchange 恢复为最近的信息。注意，Exchange 会根据需要自动将事务重新播放到恢复的数据库中。

　　备份程序访问 Exchange 数据库信息的方式是通过可扩展存储引擎 (ESE) 备份 API 或更新的 VSS 解决方案(稍后我将介绍这些新的解决方案)。只要启动 ESE 备份，Exchange 就会暂时挂起向其数据库进行的所有写入。在 ESE 暂时将数据库设置为只读模式以便能够在完整备份过程中对其进行复制的同时，它还会使用一个临时数据库来保存在备份过程中发生的新事务。当备份完成后，ESE 会将数据库返回正常的读/写模式，并应用累积在临时数据库中的事务。成功完成备份后，最后还会清除掉旧的事务日志。

　　即使对于在半夜时分备份正在进行时登录的用户，此备份过程也是直接和透明的;虽然如此，ESE 仍然需要很长时间才能完成，特别是因为 Exchange 数据库的规模跨度很大，可以从几千兆字节到可管理的 30 到 50GB，甚至高达 100GB——如果使用标准技术，几乎一整夜也无法完成备份。要初步了解使用 NTBackup.exe 时的可用选项，请看一下图 1。

　　

　　图 1 使用 NTBackup 实用工具

　　Exchange 最佳实践

　　如果希望能够迅速从常见硬件和系统故障中恢复，应在夜间运行完整的 Exchange 备份。为改进 Exchange 服务器使用本地磁盘时的性能和恢复能力，应使用单独的 RAID 阵列来存储 Exchange 数据库和 Exchange 事务日志，这一点很重要。这样，如果 RAID 阵列控制器出现故障，或者如果阵列中的多个磁盘出现故障，使得剩余磁盘无法再重新构造条块化的数据时，您仍然能够进行恢复。如果丢失了事务日志，您仍然可以在其他驱动器上获得最新的 Exchange 数据库，从而能够继续使用新事务日志进行正常操作。如果丢失了数据库驱动器，此时的恢复策略应是返回到前一夜的 Exchange 数据库的完整备份，然后应用当前日期的事务日志使之保持最新状态。

　　限制 Exchange 数据库的大小非常重要，以便能够以合理的用时备份每个数据库——更重要的是，能够进行恢复。对多数组织来说，这意味着需要使数据库的大小保持在 30 到 50GB 之间。如果数据库超出该大小，则建议将其拆分成多个小数据库，以便能够对恢复进行管理。

　　备份和恢复连续性

　　数据库和事务日志的放置位置非常重要——不仅仅是对于备份性能，还事关恢复速度。今天，所有服务器都支持各种级别的磁盘驱动器冗余(称为 RAID)。从基本上讲，RAID 使得磁盘驱动器出现故障时不会导致系统崩溃，但在更换和重建磁盘之前系统性能会降低。在此期间，为响应每个磁盘的访问请求，阵列控制器必须动态地使用剩余磁盘重新构建数据。有关邮箱服务器存储设计的详细信息，请参阅 Microsoft IT Showcase 文章“Exchange Server 2007 的 64 位应用”。

　　Exchange 的核心功能是其单实例数据库设计。这意味着在一个 Exchange 数据库中，只会存储一个特定邮件消息副本以及一个附件(如果有)。如果该邮件是发送给同一信息存储区中的多个收件人，则会创建指向相应对象(邮件、附件)的附加指针，但不会复制对象。这不仅对提高传送效率很有好处，还可以为 Exchange 节省磁盘和磁带空间。

　　由于 Exchange 只擅长恢复整个数据库，因而单个邮箱、文件夹或邮件的恢复会要求先恢复整个磁带。毫无疑问，用户会希望具备更小单位的恢复能力。磁带的这种单实例特性使之非常难以实现。针对此需求，备份服务供应商采用了“程序块级备份”(Brick-Level Backup) 技术(本人并不建议采用此技术)。使用认可的 ESE 备份 API 完成 Exchange 的完整备份后，备份产品会将每个邮箱添加到备份磁带上。因为该备份 API 并未提供一种从单个邮箱中提取数据的方式，所以使用了 MAPI。结果，备份磁带由于复制了所有邮件和附件而变得非常长。

　　Microsoft 提供了一些增强功能，可部分解决这一问题。例如，管理废纸篓(或转储程序)会在用户将某些数据删除后，将其保留一段时间，以防再次需要。此外，不再需要保留一个备用服务器作为 Exchange 恢复林;恢复存储组允许管理员部分装载从磁带上取回的已恢复数据库，并将数据复制或合并至邮箱级别。

　　熟能生巧

　　许多组织都曾领教过一项艰巨的任务，即不管决定在哪个级别上进行备份和恢复，都必须定期对备份媒体和恢复过程进行测试。许许多多管理员都是在灾难发生后才知道其备份技术和恢复过程是否能够正常工作。最佳的测试时间是在建立和配置了崭新的服务器之后，当它已经开始作为 Exchange 组织的一部分运行，但上面只有很少的用户时即开始。此时，您应当执行一次 Exchange 完整备份，并定期备份您的驱动器，此外还要捕获系统的状态，其中包括系统磁盘上的重要文件和 IIS 元数据库(其中存储了 Exchange 的路由配置)。然后，小心地重新格式化该新服务器并重新启动，更新最初构建服务器时获取的注释。您应当能够从系统状态中恢复设置，同时还要具有足够的文档来手动重新实施系统配置的设置。

　　在这种“消防演习”上花些时间可显著减少将来的恢复操作所需的时间。您应当定期重复此过程。执行此任务时，可记下从离站位置获取磁带所需的时间。那些在此期间不得不耐心等待的用户经常会开始认真考虑磁盘到磁盘备份在其备份和恢复策略中所能起到的重要作用——即使离站磁带存储仍然为灾难恢复提供了最终支撑。

磁带备份面临的挑战

　　从磁带中恢复需要很长时间。现在，Exchange 对于组织来说是如此重要，以致于用户和管理者希望它能够始终处于可用状态。当出现严重问题时，大多数组织都感到措手不及。没有人会想到从磁带中恢复 75GB 的数据库居然需要八个小时——而这甚至还未包括从离站存储设施中获取磁带或重新安装操作系统所需的时间。

　　此外，从磁带中检索正确的数据库也是一项严峻的挑战。自从 Exchange 首次面世以来的 10 年时间里，磁盘存储和广域网的成本已经有了大幅下降。这使得许多组织能够支付更快的备份和恢复方法的成本。这些组织可以利用相关技术，为其 Exchange 基础结构实现操作的连续性和灾难恢复功能。

　　级别 2：操作连续性

　　操作连续性是一组旨在使恢复过程尽可能迅速完成，同时尽量缩短意外停机时间的过程和技术。操作连续性针对通过磁带进行的本地恢复提供了改进的恢复时间目标 (RTO) 和恢复点目标 (RPO)。它力争消除(只要有可能)使磁带重新入站所需的时间。请参见图 2 以比较备份和恢复的操作连续性与灾难恢复。

　　

　　图 2 恢复连续性 (单击该图像获得较大视图)

　　该图显示了恢复和可用性的连续性，左下角的技术速度慢、成本低;右上角的技术速度快、成本高;同时在操作连续性与灾难恢复解决方案之间有意进行了一下模糊过渡。

　　该图揭示了这些方法在成本、恢复时间和可用性之间的取舍状况。在本文中，我会刻意将本地连续性处理与灾难恢复明确区分开来。灾难恢复始终被视为一种远程操作，并以使数据离站为主要目标。距离带来了额外难度，并且通常成本更高，但灾难恢复是有关严重灾难性事件后的业务继续的措施。稍后我将深入探讨这一问题。

　　一些历史

　　随着 Exchange 在基础结构中的地位越来越重要及其数据库中存储的信息越来越多，显然有必要减少备份和恢复所需的时间。某些大型组织与 Microsoft 协同工作，开发出一种方法，大大改进部分操作的恢复。如果某个组织可以从外界接收或向其发送新电子邮件，则表面上看起来好像什么也没有发生。毕竟，表面现象是很重要的。

　　为实施 Exchange 的这种“拨号音”式恢复，一个新的空数据库取代了被破坏的数据库。然后，Exchange 和 Active Directory® 使用适当的权限创建新邮箱，使得用户能够发送和接收邮件。当检索了备份磁带并恢复了数据后，可使用管理权限进行装载。然后，Exchange 管理员可以将恢复的邮箱合并到拨号音邮箱中。可根据需要划分邮箱的优先级。虽然这是一项改进，但该过程很耗时，也比较复杂;它最初使用了 EXMERGE，后来应用到了恢复存储组中。不过应当注意，拨号音恢复方案之后的完整数据恢复会是一项非常艰巨、复杂的任务(尤其是在 Exchange 2007 中，存储组可多达 50 个)。如果考虑实施拨号音恢复方案，请注意确保益处大于付出。

　　卷影复制服务

　　为利用低廉的磁盘并从生产 Exchange 服务器中消除处理器开销，针对 Microsoft® Windows Server® 2003 和 Exchange 开发了一个新备份 API。所创建的卷影复制服务 (VSS) 旨在提供一致的数据时点副本。这些快照是可迅速生成的 Exchange 数据的只读副本，其中只连续包含发生更改的数据。这些副本通常指向另一个具有可用磁盘空间的服务器，或者指向存储区域网络 (SAN)。可以保留多个快照，并在磁带上制作备份。这样一来，生产 Exchange 服务器将不再受到备份软件和磁带副本开销的性能影响。

　　使用 VSS 进行 Exchange 数据保护具有多个优点。首先，可以从 Exchange 服务器中消除磁带备份操作的性能负载。虽然仍然需要备份到磁带，但它可以使用 Exchange 数据的副本，而不影响用户性能。其次，每晚多次获取快照成为可能。随之而来的另一个好处是您可以在辅助服务器上或其他本地存储中保留多个快照。

　　市场上有许多第三方产品利用了 VSS 快照功能。有些产品只是减少了备份和恢复 Exchange 数据库所需的时间，另一些产品还添加了某些功能，例如比本机 Exchange 所能提供的单位更小的恢复能力，使您能够恢复至邮箱级别。虽然没有人喜欢如此零碎的备份，但人们确实希望能够恢复特定的文件夹，甚至单个邮件消息。

　　复制技术

　　以软件为媒介的 Exchange 故障转移是某些复制供应商提供的一个选项。它将激活一个备用 Exchange 服务器，然后通知 Active Directory 所有用户的邮箱已经移走。有两种方式来完成此任务，并且它们都要求对 Exchange 和 Windows 环境进行某些自定义。一种需要对 DNS 用一些小技巧，使得备用服务器能够获取故障服务器的名称和 IP 地址。这种方法的优点是客户端工作站方面会比较简单，因为 Outlook® 会认为它仍在使用相同的服务器。

　　第二种方法使用一台运行 Exchange 的备用服务器，其上存储了数据库的副本，但并未进行任何装载。出现故障时，该备用服务器将通知 Active Directory 所有用户的邮箱已移到它那里。然后将运行一个脚本或发布一个组策略，告知客户端它们位于不同的邮件服务器上。Outlook 2007 能够识别 Active Directory，这使得该过程变得更简单，因为它自己就会自动识别出这些映射。

　　使用 MSCS 的本地群集

　　可用性连续性的高端是 Microsoft 群集服务 (MSCS);Exchange 是能够识别群集的应用程序。群集可在两台或更多台计算机之间共享信息，这样如果其中一台出现故障，其他计算机可接管其工作。今天，大多数 Exchange 群集都有两个或四个节点，最多可以使用八个节点。始终会指定一个节点作为被动节点——可在 Windows Server 正在运行且安装了 Exchange Server 的情况下操作，但没有活动的邮箱。Exchange 2003 提供了一种两节点的主动/主动群集，但是由于性能负载的原因，现在不建议使用它，Exchange 2007 将不再对其提供支持。

　　针对 Exchange 2003 的群集方式，包含一个被动节点的 Exchange 2007 群集仍然可以使用一个单一的共享存储阵列。虽然群集品质的存储阵列通常具有许多冗余功能来防范多种类型的故障，但它们仍然只提供一个数据副本，这留下了一个隐患。这就是为什么这些群集被称为单副本群集 (SCC) 的原因，以区别于 Exchange 2007 中的多副本群集 (MCC) 所带来的下一代数据保护手段。我们将在说明灾难恢复时进一步讨论 MCC。

　　本地连续复制

　　本地连续复制 (LCR) 是 Exchange 2007 的一项新功能，它提供了一种改进方式来维护同一服务器内 Exchange 数据库和事务日志的第二份副本。这为使 Exchange 数据库和事务日志分别位于不同 RAID 阵列中的最佳实践添加了一个冗余层：利用 LCR 可以在存储数据库主副本的阵列中存储一份日志的辅助副本，然后在存储日志主副本的阵列中存储一份数据库的辅助副本(参见图 3)。如果其中任何一个 RAID 控制器或阵列本身出现故障，您仍然可以使用另一个阵列中的数据库和事务日志。通过这种方式，您可以继续操作——虽然这会令人感到有些紧张，并且性能会有所降低——直至能够将出现故障的阵列重新建立起来。

　　

　　图 3 配置 LCR

LCR 是一种本地操作连续性解决方案，而不是一种备份方案，因此您仍然需要一个完整备份策略。使用 LCR 还有一个性能损失，因为您的服务器现在要制作数据库和事务日志的两份副本。此外，在 Exchange 2007 的实现中存在一些限制，使得 LCR 只适用于较小的组织，因为 LCR 只支持某个存储组中的一个数据库，以及某个组织中的一个公用文件夹数据库。

　　使用 LCR 恢复功能实现的故障转移不是瞬间即可完成的——必须要由一位有经验的 IT 专业人士通过运行脚本来备份 Exchange。该过程要求执行在 Exchange 管理控制台之外运行的 Exchange 命令行管理程序命令。

　　Exchange Server 2003 Enterprise Edition 使组织最多能够运行 20 个 Exchange 数据库(四个存储组，每组最多五个数据库)，而 Exchange 2007 Enterprise Edition 允许使用多达 50 个存储组，每组都有自己的数据库。事务日志也从 Exchange 2003 中的 5MB 文件减少为 Exchange 2007 中的 1MB 文件。这两项变化都是设计来支持 LCR 的——外加群集连续复制 (CCR)，它在某种程度上也与此相关。

　　中小型组织将使用 LCR 以便为其 Exchange 操作提供改进的数据保护。LCR 易于实现，但仍然需要手动干预。作为一种“同一服务器/本地磁盘”解决方案，LCR 只是迈向改进的操作连续性的第一步。虽然它确实能够针对 RAID 阵列和 RAID 控制器的故障起到保护作用，但多个磁盘或 RAID 控制器同时发生故障的可能性是很低的。多数情况下，故障方案涉及整个服务器的崩溃，这将我们引向了 Exchange 保护中的下一步。

　　第三方本地非主机复制

　　为进一步提升 Exchange 的恢复能力，第三方供应商开发了一些利用“非主机”复制方式的产品，使用 Exchange 日志文件在另一台计算机上保留一份 Exchange 数据库的备用副本。在这种情况下，数据保护或归档解决方案将执行一个 Exchange 的 ESE 完整备份，将其备份到另一台计算机上，然后在 Exchange 关闭事务日志时立即将其取出。它会将这些事务日志插入到其 Exchange 数据库副本中，以使其始终保持最新状态。如前所述，这些日志很小(在 Exchange 2003 中为 5MB，在 Exchange 2007 中为 1MB)，因此当完整备份完成后，将这些日志文件复制到非主机服务器上几乎不会给 Exchange 服务器带来任何系统开销。

　　级别 3：灾难恢复和高可用性

　　灾难恢复是指在主要数据中心不可用时将它重新建立起来并恢复运行的能力。Exchange 需要具备有效的灾难恢复能力，因为电子邮件和日历功能在今天已经成了许多组织的命脉。

　　有些公司将其传统的离站存储磁带备份作为某种形式的灾难恢复措施，但是如果您唯一的数据中心遭到火灾或水灾破坏，那么即使用车拉来成卷的磁带也毫无意义。灾难恢复实际上不仅仅是将数据移到另一处位置，还涉及恢复应用程序并使之运行的技术和过程。要实现有效的灾难恢复，需要让主系统和辅助系统相隔一定距离。地点相隔距离的远近取决于考虑要克服的灾难的量级。如果您担心失火，那么或许园区内的另一栋建筑已足够远。但是，涉及火车或飞机失事的基础设施灾难可能会影响 1 英里或 1 英里以上的半径范围。许多灾难是区域性的：洪水、冰雹、地震甚至停电等。通信也可由于自身的灾难而陷入困境——从切断与您的 ISP 之间的链接的反铲问题到拒绝服务攻击，直至针对一般商务的 Internet DoS 攻击。

　　在实践中，如果您的组织已经在多个地点配备了 IT 员工，那么针对您要防范的灾难类型，其中一处位置可能会符合您的远程操作连续性标准。与求助于灾难恢复服务提供商或在新位置租用空间相比，使用自己的设施和员工要更经济。

　　灾难恢复的终极目的是给人一种感觉：使客户确信您的业务仍在运行中。当灾难袭击某个城市或地区时，人们对此可以理解;但是如果您的公司在几天到一个星期之内没有恢复正常，那么很有可能客户和供应商会做出最坏的猜想;许多公司都因此而落败下去。对于客户来说，您的运营必须看上去已经恢复正常，以使他们确信您的业务仍在继续。客户对恢复的及时性存在不同认识：与办公家具供应商的暂停运营相比，他们对金融服务公司的暂停运营更易失去耐心，这很容易理解。

　　灾难恢复要求

　　如果希望能够在灾难后使 Exchange 重新在线，需要将其数据复制到一个辅助地点，并使用适当复制技术将数据提供给一个已准备好运行这些数据的预热 Exchange 服务器，然后通知 Outlook 客户端它们的邮箱已经移走。

　　Exchange 在复制方面的要求较高，尤其是在距离较远时。对于真实的事务数据库，每个写入的顺序极为重要。使问题变得更加复杂的是，Exchange 使用 SMTP 传输协议在服务器之间传输所有事务和系统信息，而这是一种非常占用带宽的协议。此外，对于 Exchange 群集，必须每隔 500 毫秒在系统之间传递一个检测信号。如果辅助节点没有收到该信号，则可能会触发故障转移。

　　解决这些问题的复杂性或许是 Microsoft 直到今天才在 Exchange 2007 中涉足这一领域的原因。在 Microsoft 尚未涉足之前，若干第三方解决方案已经开发出来，它们使用基于主机或基于阵列的复制功能来复制 Exchange 数据。

　　供应商意识到他们可以通过将节点分散到不同位置来扩展一个群集，这称为扩展群集。今天，要实现扩展群集，最常见的方式是使用通用的第三方数据复制产品或那些专门为扩展 Exchange 节点而开发的产品。您可以使用 MSCS 完成此任务，但 WAN 上的子网要求是个难点。向远程数据中心提供可靠的高带宽连接是很复杂的，再加上群集，无疑会增加建立、维护和定期测试灾难恢复系统的成本，并会提出更高的人员要求。

　　群集连续复制

　　Microsoft 通过 Exchange 2007 中的群集连续复制功能扩展了它对群集的支持。CCR 扩展了 LCR 的功能，现在能够维护两个 Exchange 数据库和事务日志副本，在两个群集节点上实现同一设想。灾难恢复意味着需要使主系统与辅助系统在地理上彼此分离，在 Windows Server 2008(原代号为“Longhorn”)使得扩展群集成为可能之前，Microsoft 多副本群集 (MCC) 无法跨越很远的距离。

　　使 MCC 节点能够具有单独的数据副本的技术称为多数节点集 (MNS)，它是指一个选举过程，其中两个或多个节点决定由谁来保存数据的活动副本。当出现故障时，其余节点将进行一次新选举以确定由谁接管作为新的主处理/数据服务器。支持这种技术民主行为的是 CCR，它将确保每个节点都具有最新的数据库。使用 CCR 的 Exchange 2007 群集被限制为只有两个节点。

　　在大型组织中，Exchange 服务器通常在服务器上配置本地系统磁盘，然后通过 SAN 连接到 Exchange 数据库(使用 SCSI、光纤或 iSCSI 磁盘阵列)。对于 MCC/MNS 群集，一个有趣的问题是高端的 Exchange 存储是否会退化到为每个节点使用本地 RAID 阵列。如果 MNS 群集的目的是使每个节点具有自己的独立存储，那么将每个节点指向旨在提供公共存储的 SAN 是否仍然有意义呢?

　　在一个中规中矩的 MCC/MNS 群集方案中，主节点会将存储放在 SAN 上，而辅助群集节点会使用本地磁盘或成本较低的 iSCSI SAN。该辅助节点可远离主数据中心，位于一个不具有 SAN 基础结构的远程位置。

　　不管其如何展开，使用 MNS 和 CCR 的 MCC 都是在冗余和增强的可用性方面取得的另一项进步，因为此时有多台计算机能够进行故障转移，并且数据在单独的存储元素上进行复制。不过，在 Windows Server 2008 出现之前，这仍然完全局限在一个数据中心内。Windows Server 2008 将提供扩展群集的本机支持，使 MNS 群集中的节点能够在地理位置上相隔任意远的距离——前提是节点之间的网络延迟能够稳定地低于 500 毫秒。直到这时(以及从此以后)，第三方群集技术才能基于 Microsoft MNS 和 CCR 提供扩展群集所需的地理分隔，以便获得有效的灾难恢复解决方案。

　　群集属于灾难恢复连续性的高端领域，而 CCR 可恰当地定位为 Exchange 的高可用性功能。即使这种结合具有较高的成本和人员要求，但对于希望获得一个同构的 Microsoft 环境的用户来说，这将是一种令人兴奋而先进的解决方案。

　　第三方远程操作连续性

　　一旦面世，Microsoft 解决方案和第三方扩展产品就将占据灾难恢复连续性的绝对高端，这一点勿庸置疑。数秒内即可自动完成故障转移——几乎尽善尽美。不过，并非所有公司都需要如此级别的可用性和业务连续性，有些也无力为此支付数十万美元的费用。对许多公司来说，能够在几分钟内完整恢复 Exchange 的可靠解决方案已经足以提供他们所需的所有操作连续性。

　　例如，Mimosa Systems, Inc. 将一个数据中心内的操作连续性扩展到远程连续性。在远程位置，Mimosa DR 维护了一个 Exchange 副本，使用来自主 Exchange 服务器的事务日志使其保持最新状态，并时刻准备着将此有效副本提供给您的备用 Exchange 服务器。远程 Exchange 服务器使用标准服务器硬件，并且就像单数据中心实现一样，您可以使其保持预热状态，时刻准备着在出现灾难时激活。一旦发生灾难，远程位置的操作员可以启动故障转移并执行故障转移，包括装载备用数据库文件以及重新映射邮箱和 Outlook 配置文件。但是需要注意，这种第三方解决方案存在一定的支持局限，知识库文章“Microsoft 针对修改或提取 Exchange 数据库内容的第三方产品的支持策略”对此进行了定义。

　　总结

　　Exchange 数据保护提供了一系列技术和过程，根据成本和功能性可将其分组为三个级别。开始考虑 Exchange 数据保护的要求时，您应当考虑利益相关者所能接受的停机时间。优异的性能和快速的恢复要求付出更高成本，高端选项都将超过六位数。更经济的解决方案旨在努力提供更高水平的可用性，但无法达到最高水平。您应根据自己组织的需要进行选择。

Service Pack 1 for Exchange 2007