ExchangeServer2007數据保护与灾难恢复.docVIP

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 只擅长恢复整个数据库，因而单个邮箱、文件夹或邮件的恢复会要求先恢复整个磁带。毫无疑问，用户会希望具备更小单位的恢复能力。磁带的这种单实例特性使之非常难以实现。针对此需求，备份服务供应商采