Exchange Server 2007 数据保护与灾难恢复.pdfVIP

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