虽然邮箱归档是很常见技术，但是并⾮每个⼈对该技术有很完整系统的理解，下⾯这篇⽂章希望能帮助⼤家对Exchange邮箱归档有个系统的理解，能够帮助⼤家在跟客户沟通，在项⽬实践中有所帮助。
本块⼉内容分成两部分，先写⼀部分，后⾯⼤家觉得不错，我再写第⼆块⼉内容。
问题⼀：为什么要归档？归档都能⼲什么？
我敢说这个问题，真正能理解“归档”这两个字的⼈并不多。归档，英⽂名Archive，实际上是⼀种⼴义的对数据存储管理的⼀个统称。重点在于如何更加合理地保存和管理数据，⽅便随时查看和调阅。其核⼼思想是如何提⾼数据的管理和使⽤效率问题。这⾥，我从以下⼏个⽅⾯谈谈归档的⽤途：
⼀、存储优化问题不是因为寂寞才想你 t.r.y
根据我和⼤多数客户的接触，发现他们对归档的第⼀需求不是保存数据，⽽是对数据的优化管理。我相信，除⾮邮件对于公司来说根本不重要，否则对任何⽹管来说都会⾯临如下这个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⽆缝集成？如果各位有兴趣，可以咨询各个⼚家的实现⽅式。⾄于孰优孰劣，其实客户是最好的裁判。
mike隋正是基于以上两个机制，终于解决了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%的性能消耗了。
发布评论