在Exchange Server 2010中，微软公司针对构成邮件应用的基础数据库结构进行了重大改动。这些改动将对Exchange Server的存储需求产生很大的影响。从本篇中，你将了解到Microsoft Exchange 2010归档的最佳实践方式。

一项可能对你的Exchange Server存储规划产生重要影响的因素是你是否计划部署用户归档邮箱，这也是Exchange 2010中新增的一项功能。用户归档邮箱作为二级邮箱，可以用于信息的长期保存。和其它Exchange归档方式的不同之处在于，比起传统的归档方式（例如日志邮箱），用户在归档邮箱中仍可以保持对各类信息的所有权。因而，每项用户的归档信息都是可以访问的。

归档邮箱的设计旨在取代原有的PST文件。不过和PST文件不同，归档邮箱会存储在Exchange Server的邮箱服务器中，并通过Exchange管理员进行管理维护。

在最初的Exchange 2010 RTM发布中，用户的归档邮箱位于其主邮箱相同的邮箱数据库中。而在SP1中，Microsoft提供选项，让用户的归档邮箱可以重定位到另外一个的邮箱数据库中，这样使得归档操作可以离线进行，不会影响到主邮箱存储。

微软通常推荐将归档邮箱部署在低端的邮箱服务器上，而且使用廉价的直连存储（比如SATA阵列）。因为要记住，如果邮箱数据库中只包含归档邮箱数据库，那么它的I/O负载绝不会像存储用户主邮箱的邮箱数据库那样。使用低成本的存储作为用户归档邮箱的另一项优势在于可以在归档邮箱上配置较高的邮箱容量。

Exchange Server 2010的归档和电子检索功能是否能够取代以往的第三方产品？

早在Exchange Server 2010发布之前，就出现了为Exchange Server提供归档和电子检索产品的行业。而目前Exchange 2010提供与身居来的用户归档和内置的电子检索功能，似乎只能从本质上分析这些新功能是否能够取代第三方产品。

对于小型企业而言，Exchange 2010归档特性已经足够了，不过对于企业级用户可能还不是这样。归档和电子检索功能在面对大多数第三方工具时还有其局限性。

例如，Exchange 2010的归档邮箱并不是完全的归档解决方案。归档邮箱允许用户将重要信息离线保存在、二级邮箱中，规避保存策略或容量限制。不过假如你希望在企业级别进行完全的归档，你仍需要使用Exchange的日志功能。而第三方归档产品则可以在信息归档、保存和处理上提供更好的控制。

对于Exchange 2010中多邮箱的电子检索特性也是如此。多邮箱检索有一些重大的局限性。例如，其只适用于Exchange 2010的邮箱中，因此你仍需要使用第三方产品来检索之前的Exchange邮箱或PST文件。

多邮箱检索功能同样缺乏一些详细的报告以及导出功能，而这在一些专业化的电子检索产品中非常常见。

日志中的把戏

另一项需要加以考虑的是日志邮箱。假如你在集线传输级别使用日志功能来归档信息，那么所有的归档信息将都被放置在日志邮箱中。

当然我从来没读到过Microsoft任何部署日志邮箱的最佳实践，不过我更倾向于将日志邮箱放在其自己的邮箱数据库中。这是因为日志处理会占用大量I/O，而将日志邮箱放在专用的邮箱数据库中可以确保其I/O性能不会影响到其它邮箱数据库的性能。当所有信息都进行日志记录以后，在同一存储中的存储日志邮箱和用户邮箱会使得I/O需求翻倍，因为Exchange 2010并不使用单实例存储。换句话说，日志功能意味着在邮箱存储过程中需要将每条信息创建一个额外的复本。

假如你要在用户邮箱的同一数据库中创建日志邮箱，这会给整个复制过程造成严重的影响。

检索邮箱

在各类邮箱中，最后需要考虑的便是对于Exchange 2010检索邮箱的规划。检索邮箱只在有多个邮箱检索（电子检索）进行时才会被用到。检索的结果也会保存在检索邮箱中。

根据默认设置，检索邮箱会被分配50GB的空间。这听上去很大，不过对于大型企业中进行电子检索而言，空间还是太小了。

当涉及到为检索邮箱选择存储位置时，容量往往会比性能更为重要。虽然电子检索同样要求大量I/O，但检索邮箱数据库中的I/O负载和用户邮箱数据库中的I/O负载相去甚远。

如果电子检索对你并不是高优先级的选项，在需要之前你甚至可以不用考虑去创建检索邮箱。而如果不是的话，那你最好将邮箱部署在专门的邮箱数据库上，而且位于低价的存储系统上，有着大量的空余磁盘。

更多的规划

很显然，在规划Exchange Server存储体系架构时你需要考虑更多一些问题。即便是Exchange 2010并不像其上代产品那样有高I/O需求，对I/O性能考虑仍是设计时非常重要的。其它关键因素还包括容量和容错能力。