Exchange 2007 数据保护和灾难恢复

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

　　级别 1：基本备份和恢复

bitsCN.Com

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

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

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

　　 bbs.bitsCN.com

　　图 1 使用 NTBackup 实用工具 DL.bitsCN.com网管软件下载

　　Exchange 最好实践 中国.网管联盟

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

BBS.bitsCN.com网管论坛

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

　　备份和恢复连续性

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

bitsCN.nET中国网管博客

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

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

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有