虽然邮箱归档是很常见技术，但是并非每个人对该技术有很完整系统的理解，下面这篇文章希望能帮助大家对Exchange邮箱归档有个系统的理解，能够帮助大家在跟客户沟通，在项目实践中有所帮助。

本块儿内容分成两部分，先写一部分，后面大家觉得不错，我再写第二块儿内容。

问题一：为什么要归档？归档都能干什么？

我敢说这个问题，真正能理解“归档”这两个字的人并不多。归档，英文名Archive，实际上是一种广义的对数据存储管理的一个统称。重点在于如何更加合理地保存和管理数据，方便随时查看和调阅。其核心思想是如何提高数据的管理和使用效率问题。这里，我从以下几个方面谈谈归档的用途：

一、存储优化问题

根据我和大多数客户的接触，发现他们对归档的第一需求不是保存数据，而是对数据的优化管理。我相信，除非邮件对于公司来说根本不重要，否则对任何网管来说都会面临如下这个she hui zhu yi初级阶段的矛盾：“人民日益增长的物质和文化需求与落后的生产力之间的矛盾”。
对此，无外乎两种解决方案：1）增大存储，2）让用户保存PST。下面我来讲讲这两种方案存在的问题：

1）增加存储的问题
这里我来举一个典型客户的案例。这个客户是一个1000多人的企业，只用了一台Exchange 2007。由于业务需要，经常需要给许多人发大型设计图纸或者其他大附件。于是用户发现1GB的邮箱其实也存不了多少东西。那些过去的邮件成了鸡肋，丢了怕以后有用，存着浪费空间。所以他们就天天吵着要IT增加邮箱Quota。而IT人员也是有苦衷的，且不说预算问题，就算存储爱买多少可以买多少，也不能每年给一台Exchange服务器加2TB的存储吧？这不是差不差钱的问题，是技术瓶颈问题。等每个人都用满2GB邮箱的时候，说不定大家又该叫速度慢了。
其实客户考虑过备份的问题，将旧的邮件备份起来，然后从服务器上删掉不就行了吗？当然这个方案很快就被否定。用户要那些邮件的时候怎么办？再找IT恢复回来？累死人

2）保存到本地PST的问题
相对于第一种方案，这种方案更受青睐一些：让用户全部下载到本地自己搞定就行了。这其实也是一种不得已而为之的推卸责任的做法。我相信许多IT人员对PST一定已经颇有微词了。PST的原罪在于：
没有保护，容易丢失：PST一般保存在那个Document and setting/…/…/…中，而且还是隐藏文件夹，不说是公司漂亮的小前台，就连我重装系统时也经常把地址本、收藏夹都备份了，唯独忘了那个该死的文件夹。从磁带恢复？算了吧，服务器上哪有东西啊。
占用本地空间，速度越来越慢：有时候IT人员不得不干一些擦屁股的事情，比如给某个领导整理一下他那个已经臃肿得不行的PST。搞个什么PST2008，PST2009之类的。眼睛和贼溜溜地盯着你，好像担心你小子什么时候给他制造出什么艳照门出来呢
邮件保存和监管的问题：如果你的公司不是太看重邮件内容就算了。但如果邮件内容承载了太多业务上的东西，那么邮件的保存就变得非常重要了。公司如此重要的数据就掌管在每个人手里，没法搜索，没法查找。你想删就删，想拷就拷，这还得了？
其它另类的问题：我听过最另类的客户痛恨PST的理由是：他们公司经常有人不小心把工资单发给不该发的人，结果发现泼出去的水，发出去的信。要是保存在服务器上还有得挽救的余地。

邮件归档方案的用途：

写到这里，你应该已经猜到了。邮件归档，就是你的第三种解决方案：一种既可以代替PST，又快要克服PST弊端的解决方案。
一个好的邮件归档解决方案，可以解决一个最关键的问题：降低一线设备的存储需求，同时不影响用户的体验。
业界一般有两种解决方案：
1）邮件扩展，或者叫去除重复数据
邮件扩展的原理很简单，即使将整封邮件或者附件从Exchange服务器上移走，并替换成一个存根。这样当用户通过Outlook打开被扩展邮件的时候，由于Form的作用，会自动从归档服务器上取回该邮件和附件。这就解决了备份方案无法解决的问题。当然在这个功能上，每个厂家的实现方式是不一样的。有的产品是将整封邮件全部拿走，有的产品只拿附件。两种方式各有利弊。前者扩展的效率更高，但用户无法预览邮件。后者只能扩展80%左右的内容，但用户可以直接查看附件之外的所有内容而无须归档服务器支持。
2）另一种思路是已归档内容的自助访问
如果用户能够在别的地方方便地访问到他过去的邮件，那何苦全部保存在收件箱中呢？
问题是，这又产生了另外一个社会问题——钉子户。你要是搬迁的安置地不好，总有用户会有意见，而且不愿意搬走那些邮件的。那么归档业界又有哪些手段来实现这个目的呢？归纳起来有三种：客户端插件、基于浏览器的BS架构、无插件的Outlook/OWA集成。 第一种方式就是在Outlook客户端安装一个插件，通过插件提供给用户一个自助访问的界面。第二种最简单，告诉每个用户，把那个地址添加到收藏夹以备后用。第三种当然是最理想的方式，不用安装插件，还和Outlook/OWA无缝集成？如果各位有兴趣，可以咨询各个厂家的实现方式。至于孰优孰劣，其实客户是最好的裁判。

正是基于以上两个机制，终于解决了SHZY初级阶段的矛盾问题，把人民内部矛盾转化成了厂商之间的阶级矛盾。所谓鹬蚌相争渔翁得利，你就等着挑性价比最高的产品就行了。

二、数据保留和法规遵从
相对第一点，相信这一点是最好理解的。因为地球人都知道归档的第一动机就是为了查询和满足法规遵从方面的需求。
这里唯一需要关注的是：归档什么内容？怎么查询？如何充分利用这些数据？
例如，大多数产品都只能通过Journaling邮箱归档收发的邮件，或者是归档客户端的PST。而一些新的产品可以实现对整个邮箱的归档。包括个人文件夹、公共文件夹、地址簿、日程、便签等。甚至还可能实现对邮件的操作记录进行跟踪。如阅读、回复、修改、删除等动作。因此，尽管概念都一样，但获取数据的差异，必然导致审计的质量。关于这一点，我们将在后面的实现部分讨论。

三、数据保护和恢复
过去大家对归档的理解，总是和备份划分界限的。实际上归档和备份之间完全可以做到统一。即使是普通的归档系统，其实也能实现部分数据恢复操作——至少我们可以把已经丢失的数据从已归档数据中找出来，然后再用各种方式发给用户。
而新一代的归档解决方案，完全可以将归档和备份恢复统一起来，将原来的“备份-恢复”模式，改变为“归档-恢复”模式。所以无论你采用什么样的归档方式，都有一定的数据保护功能的，只是产品不同，实现的程度不同而已。而实际上，用归档代替备份是一个大的趋势。因为相比备份方案，归档方案更加智能和精细。可以说，未来的归档，将会是一个智能的、精确的备份系统。

因此，综合起来，归档不但能够解决我们常规的数据保留和查询问题，其实还解决了其他两个问题：存储管理和数据保护。

问题二：如何实现归档？

上一章，我们讲到了邮件归档的需求驱动问题。下面，我们来讨论一下Exchange归档的技术实现问题。
一套归档系统，所有产品都不外乎涉及如下几个环节：数据获取、数据存储、数据访问、数据应用。我们就来分别从这几个环节开始，讨论各个产品在实现上的差异。

一、数据的获取方式。
我觉得这是归档产品中最核心的一个问题。所谓巧妇难为无米之炊，获取到的数据的丰富程度，往往会影响到一个产品的整体功能。
针对Exchange来说，有三种方式可以获取到数据：MAPI协议、日记邮箱、事务日志。目前来看，除了Mimosa之外，其它产品大部分使用日记邮箱方式，少部分会通过MAPI协议做一些补充。

MAPI获取方式：
归档服务器通过给某个账户授权，让其可以通过MAPI协议访问所有用户邮箱，从而获取到想要的数据。这种方式的优点是可以直接对邮箱进行读写操作，包括前面说到的邮箱扩展即邮件存根化的动作。但缺点也很明显。第一是服务器负担很重，因此只能放在闲时执行。第二是这种方式不是连续获取的，因此不能获取到所有数据。例如每天凌晨做归档，那么白天产生，并且被删除的邮件就没法归档。保存到PST的邮件更是没有办法归档了。

Journaling方式：
这就是我们熟知的日记邮箱方式，也是通过Exchagne自带的日记功能，把所有该存储组下接收和发送的邮件都抄送一份到日记邮箱。
相对于MAPI方式，Journaling能够完整地记录下所有进出的邮件。而且依赖于Exchange 2007的加强功能，还能实现策略归档。
但是，Journaling方式本身也有它的技术局限。主要表现在如下几个方面：
1）增加服务器和存储组的负担。根据一些统计资料，开启Journaling功能会增加35%左右的负载。而且会直接加重存储组的负担。按照经验值，如果要开启日记邮箱功能，最好是先将Exchange的内存增加到1.5-2倍，这样才能保证Exchange没有太明显的性能变化；
2）并非真正获取到所有数据。如果我们把所有数据的全集定义为“进出邮件”的话，日记邮箱获取的数据是完整的。但如果全集定义为“邮箱中的数据”的话，那么它就是不完整的。因为有许多信息Journaling无法获取。实际上Exchange邮箱中有许多Message Class,邮件只是其中之一。其它Class还包括日程、联系人、任务、便签、日记等。此外还有个人文件夹的层次机构、公共文件夹、信息的元数据（Meta Data）等都是无法获取的。元数据包括信息的传递、阅读、修改、操作等信息。而这些是记录一封邮件整个生命周期的重要信息。因此从这个角度来看，Journaling方式获取的数据实际上是很不完整的。举个简单的例子：如果你的系统正使用OCS，那么这种方式无法归档到其中的语音邮件、传真邮件、聊天记录等。因为这些信息并不通过MTA的方式投递。

Log Shipping（日志传输）方式：

由于这是一个全新的概念，我将多浪费点口舌。如果你对具体技术不感兴趣请绕行。
可以说，Log Shipping技术用于Exchange数据传输是Mimosa的首创，甚至先于微软公司的CCR/LCR之前使用。
早在2003年的时候，Mimosa就通过研究和破解微软Exchange事务日志的方式，寻求一种下一代的归档解决方案。经过两年的努力，终于在2005年的时候将Log Shipping技术运用到炉火纯青的地步。在Exchange 2007的CCR和LCR还没有诞生之前，Mimosa就已经实现了针对Exchange 2000/2003的数据实时复制方案，即Exchange服务器的双副本容灾。直到Exchange 2007才将Log Shipping技术应用到CCR和LCR中。因此可以说Mimosa的Log Shipping技术，是CCR和LCR的技术蓝本。实际上Mimosa实现的准CCR和Exchange的CCR是有一些差异的。首先Mimosa的“CCR”不受Exchange版本控制，2000/2003/2007都可以，而且不分标准版还是企业版。其次不受存储组规划的限制。大家都知道CCR有一些限制，就是一个存储组下面不能有多个EDB，而且如果有公共文件夹的话，还不能是多个。而这些在Mimosa上都没有限制。当然这里Mimosa只提供容灾功能，只是方便你快速恢复系统，并不能替代CCR的HA方案。

这里，我来介绍Log Shipping的几个技术环节，供大家研讨：
第一步叫做Full Copy或者Log ship。如果系统第一次上线，则需要一次性将原来的存储组同步过来，并同时拷贝所有还未提交的事务日志。如果不是第一次，则只需用拷贝事务日志即可。实际上这里的日志传输是动态的，也就是当一个日志完成并写入到硬盘的时候，Mimosa的NearPoint系统将会基于事件驱动，立即将日志通过局域网拷贝过来，并保存在一个临时位置。
第二步叫做Log Replay。这一步的操作，就是以Exchange相同的方式，在归档服务器上对日志进行重播，从而获得所有日志中相关的数据。这个过程不占用Exchange任何资源。
第三步叫做Smart Extract（职能分拆）。我问过Mimosa的核心开发工程师，他们说这一步才是Mimosa的技术核心。其实日志重播很多厂家都能实现，但如何准确获得里的数据才是关键。因为微软的LOG原本就不是一个给第三方使用的标准接口，因此据说里面非常混乱，不但有许多重复数据，而且同样的数据会被分拆得七零八落，并且还可能是乱码。这也是有些基于Log Shipping实现的备份，有时候也不能恢复系统的原因。因为生产环境的数据破坏动作，往往也会被备份系统原封未动记录下来。那么职能分拆的目的就是将里面的所有对象全部肢解出来。例如邮件的信头、正文、每个附件、联系人等。甚至还包括了邮件的元数据。
第四步叫做Index。顾名思义，就是对所有对象进行全文索引。其实还不止如此，是需要给每个对象进行标准化，让每个对象都是有明确门牌号的。
第五步叫做全局单副本。经过索引后的对象，可能原来的存档记录就已经存在，这个时候，该对象就不需要重复保存了。直接利用原来的门牌号即可。这样的好处是可以实现跨邮件服务器、跨存储组以及对话线程的全局单副本。
这样，数据就会被无损地保存到Mimosa的归档系统中。当然在分拆阶段，可以基于管理员的策略忽略掉一些不需要的文件夹，例如Junk Mail等。已经归档过的Log文件在Mimosa上就没有用了，因此会被自动删除。同时如果客户没有第三方的备份系统，Mimsoa将会同时清除生产环境下的Log文件，避免了手工方式的日志清理。
不过需要注意的是，如果使用Mimosa，你必须禁用掉循环日志。

另外，Mimosa还有一个很好的“多点网格架构”模式，就是可以像Exchange 2007那样，用不同的服务器实现不同的角色分配。而且这些角色是可以进行热拔插的。即可以在不需要重启服务的情况下修改服务器的角色，实现性能的动态分配。这样的好处是可以很容易地进行系统扩展，而且服务器和存储之间不需要绑定对应关系。

二、数据保存问题

其实数据保存这一块可说的不多。但各个厂家的实现方式还是有很大的差异。
其中有一些比较小的产品，会把所有数据保存到SqlServer数据库中。我就见过一个在线测试的产品，他们是自动在SQL 服务器端不断建立新的数据库。好像是一个月一个？ 这种存储方式自然不能满足大系统的需求。如果将1TB的数据完全保存在数据库中式不可想象的。因此如果你是一个大系统，建议你不要采用这种方式的产品。
相比之下，大多数企业级解决方案的产品都是采用数据库+文件系统的方式保存。这样不但扩展性好，而且索引的性能更高。

这里我重点介绍Mimosa的保存方式。

Mimosa经过Log Shipping之后，会将数据保存在三个地方：IOR、Index两个硬盘卷，以及SqlServer数据库中。其中IOR叫做“已索引对象库”，就是前面说过的经过职能分拆，并且经过全文索引和全局单副本后的对象。而Index，则是这些对象的索引值，也就是如何快速找到这些对象的索引地址。那么SQL中都保存什么呢？实际上主要是邮件的元数据。包括邮件的操作记录、对话线程信息、投递过程等。因此在性能方面会更加适合于大型企业。
这里可能还会涉及的一个数据压缩的问题。目前，数据压缩往往成为归档产品的一个卖点。实际上每个厂家对压缩的理解并不一致。
部分产品只是对存储数据进行了压缩，并未实现全局单副本。这样综合下来的结果是压缩比例有限、访问速度降低。后来单副本技术已经成了一种通用技术，因此目前绝大部分产品都已经支持单副本技术了（当然也还是有部分产品没有实现）。至于数据压缩问题，我觉得这是一个双刃剑，一方面能够节省部分存储空间，另一方面又会降低访问速度，并且耗费系统资源。因此，即使是采用数据压缩的产品，也都会采用性能优先的方式，所以压缩效果不会太明显。其实压缩本身不是什么新技术和难技术，是否对数据进行压缩，不是技术问题，而是态度问题。这里Mimosa就没有采用数据压缩方式，因此也经常成为被攻击的把柄。不过这得与失之间，应该可以找到一个好的平衡点。这取决于客户是更关心20%的存储空间还是关心20%的性能消耗了。