一套归档系统，所有产品都不外乎涉及如下几个环节：数据获取、数据存储、数据访问、数据应用。我们就来分别从这几个环节开始，讨论各个产品在实现上的差异。

　　数据的获取方式是归档产品中最核心的一个问题。所谓巧妇难为无米之炊，获取到的数据的丰富程度，往往会影响到一个产品的整体功能。

　　针对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服务器的双副本容灾。实际上，微软并非一开始没有想到用Log技术，据内部信息说，是有一些操作细节在早期版本中还没记录在日志中，因此直到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。如果系统第一次上线，则需要一次性将原来的存储组通过ESE引擎同步过来，并同时拷贝所有还未提交的事务日志。如果不是第一次，则只需用拷贝事务日志即可。实际上这里的日志传输是动态的，也就是当一个日志完成并写入到硬盘的时候，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那样，用不同的服务器实现不同的角色分配。而且这些角色是可以进行热拔插的。即可以在不需要重启服务的情况下修改服务器的角色，实现性能的动态分配。这样的好处是可以很容易地进行系统扩展，而且服务器和存储之间不需要绑定对应关系。