博主语：关于邮件归档，很多人肯定都知道或者正在使用。但是真正理解归档的可能甚少。我也是知晓一二，却不能详细的阐述。偶从网上寻得此文，与各位共享。文中作者以Momsia产品为例较详细的讲解了邮件归档技术。
原文：http://solution.watchstor.com/sme-121678.htm
若本转载有侵权之处，请与我联系，立即删除！
2010-01-28 15:48 来源:Watchstor网络整理
摘要：真正能理解“归档”这两个字的人并不多。归档，英文名Archive，实际上是一种广义的对数据存储管理的一个统称。重点在于如何更加合理地保存和管理数据，方便随时查看和调阅。其核心 思想是如何提高数据的管理和使用效率问题。
问题一：为什么要归档？归档都能干什么？
我敢说这个问题，真正能理解“归档”这两个字的人并不多。归档，英文名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%的性能消耗了。
下一章将会讲到如何访问已归档数据、如何充分利用已归档数据，以及最终用户体验的问题，敬请关注。
◆四、关于存档数据的应用问题
数据保存下来了，怎么样能让这些数据充分发挥它的用途也是一个有意思的问题。
大多数人都知道，已经归档的数据可以用来自助查询、自助恢复、邮箱审计等。归纳一下，已归档数据可以实现如下几个方面的应用：
1)去除重复数据和存储优化：
就是前面说的邮箱扩展功能。当服务器上的内容已经对象化保存在归档服务器上的时候，我们就完全可以基于策略，将生产环境上的相同数据都替换为一个存根。这样的就可以大大降低一线存储的需求，而且降低了Exchange信息存储的负担。
2）用户自助查询：
方便员工随时查询自己的历史邮件，提高员工的生产力
3）数据保护和灾难恢复：
一般情况下，归档和备份似乎是不搭界的。但归档系统已经越来越多地开始承担起该任务
4）内容审计和法规遵从：
关于这一点的争议比较多。许多用户说要不是上头有条款要求，我用它来干嘛？这可能也和客户本身的应用相关。有一个客户，他们主要为国外定制建造一些大型设备，建造周期18-24个月。这中间有许多商务和技术都 是通过邮件来沟通的。
因此总是法律纠纷不断。这个时候，邮件归档就变得非常重要了，是一个可以为自己的律师团队提供有力证据的系统。所这里我想纠正一些用户的理解误区：归档不是准备好让人来查我们自己的，而是为了方便我们自己保留证据，增加我们在法庭辩论上的战斗力。（当然如果对自己不利，你别提供就好 了）
呵呵，可能有高手说这些都太基本了，是归档系统够应该有。但别着急，我只是力图给大家呈现一个完整的归档解决方案而已。下面我讲一点我认为有一些新意的东西。
关于邮件恢复
就像前面说的，好像用归档来做数据恢复时一件狗拿耗子的事情。因为备份是为了容灾，而归档是为了查询。但事务总是在发展的。早期的归档系统可能不具备数据恢 复能力，而现在的许多解决方案中都有数据恢复功能了。将两者合并起来的好处是使用更加方便，而且还可能节省更多的空间。
在业界，这类产品也分为两大阵营：一是在备份系统中集成邮件归档功能，二是在邮件归档系统中加入备份功能。Mimosa属于第二种。
前面讲过通过Mimosa的客户端集成自助访问方式，用户和自助审计员能够实现自助恢复功能。那么管理员如何从后台实现批量恢复呢？
下面是控制台的恢复范围选择截图：
从上图可以看出，管理员只需要一个右键，即可选择不同的恢复范围，包括整台服务器、存储组、数据库、单邮箱。当然公共文件夹也是可以恢复的。不过管理台不能实现单条目的恢复，必须切换到自助访问界面。
当然，也不能说Mimosa就能够完全替代常规的备份系统了，因为各自都有优缺点：
1）Mimosa归档系统可以实现数据持续保护，降低数据丢失
2）Mimosa的恢复动作非常简单灵活，在日常IT工作中比大型备份系统更方便使用
3）不需要额外的备份存储空间，提高数据的保存效率。磁带备份的话存在重复备份问题
当然Mimosa也有它的缺点：
1）只能备份一个最新的副本。因此无法将Exchange系统恢复到指定的某个时间点。例如恢复到上周三的状态。（不过不知道什么情况下客户只能恢复到以前的某个时间而不能是现在）
2）Mimosa只备份邮箱数据信息，没法保护AD和系统中的数据
3）归档系统出于安全考虑，也需要对其数据进行备份
因此，对于一般的中小型企业，只使用Mimosa归档也能基本满足数据保护功能。对于大型企业，可以考虑将备份和归档结合起来，让其发挥其各自优势。
关于系统容灾：
前面说过，由于采用Log Shipping方式获取生产环境的数据，因此相当于归档服务器上有了一份和生产环境完全一样的副本。这就给容灾方案提供可能。
Mimosa提供四种容灾方式：本地Exchange热备、本地Exchange冷备、异地Exchange+Mimosa热备、异地Exchange+Mimosa冷备。
在实际应用中，由于Exchange2007已经提供了高可用性解决方案，因此实际上这些方案的吸引力就大大降低了。不过我觉得在这四个方案中，Exchange的本地冷备最实用，性价比也最高。简单的实现方式我解释一下：
1）在生产环境中部署第二台Exchange服务器作为备机，但不开任何用户。配置好Mimosa的容灾参数。关掉备用Exchange服务器；
2）当生生产环境的主服务器崩溃时。开启Exchange备机，在Mimosa管理台上执行灾难恢复动作。然后就等着服务自动恢复到备机上即可。
实现的步骤是：
1）NearPoint 把所有归档服务器上的最新EDB拷贝到备用Exchange上
2）然后自动批量执行如下操作:
Rebinds mailboxes in Active Directory
Re-homes Exchange Roles and Services
Re-homes Public Folder Store
Cleans up system mailboxes and remove duplicate items
Restarts Exchange Services
Restores Outlook service to end-users
可能许多高手说，这不是很简单吗？按照标准的流程，通过磁带恢复也一样能一步一步搞定。问题是并非所有用户都是高手，尤其第二步经常会把人搞得头晕眼花的。 所以，Mimosa其实只是充分利用了Log Shipping的数据，然后代替管理员做一系列自动的动作而已。所以，你别把它理解为一个HA的方案，而是一个帮助你尽快让系统跑起来的工具。
关于eDiscovery和内容监控
所有归档产品都应该提供eDiscovery功能，当然功能会有差异。
这里我介绍一下Mimosa比较特别的地方：邮件对话线程追踪、重现邮件生命历程、重现邮箱现场。
邮件对话线程追踪。可以知道任何一封邮件的不限层次的对话线程。包括BCC信息也能捕捉到。由于是基于元数据和UID实现，因此不会因为邮件内容主题修改而改变。
Mimosa的邮件对话线程追踪、重现邮件生命历程、重现邮箱现场
重现邮件生命历程。一封邮件从产生到结束，中间是有许多环节的。有时候某个中间环节反而是审案的关键。而Mimosa由于通过Log Shipping方式记录了大量元数据信息，因此知道该邮件的所有后续操作：
Mimosa通过Log Shipping方式知道邮件的所有后续操作
重现邮箱现场。如果没有邮件的元数据，那么已归档的邮件呈现在我们面前的时候就只能是一维的，即你只知道一封邮件什么时候产生，但不知道它什么时候结束。
因此你也不可能知道某个时刻用户的邮箱里到底都有些什么东西。就是说，你不能提供某封邮件“不在场”的证据。而Mimosa正因为有了这些信息，所以可以利用自助审计界面，将审查对象的邮箱，重新回滚到“某年某月的某一天”，看看到底像不像“一张破碎的脸”。
Mimosa自助审计界面
此外，Mimosa还提供了一个内容智能分级和监控的组件。这里我不打算浪费大家的时间了。你只需把它理解为一个“无人值守”的eDiscovery即可。 因为你只需制定好策略，它就会帮你定时收集好各类信息，并代替审计员实现自动标记、Hold、Share等工作。不过有意思的是它可以把满足条件的邮件信 息，通过邮件的方式及时警告道管理员或者审计员。当然你别指望它会把它拦住，因为归档系统都是事后诸葛。
好了，为了写这玩意儿都没睡好觉。当然也非常感谢各位版主的鼓励和支持。
这里我想重申的是：我不想因为我的帖子导致其他厂家的心里不舒服，我没有刻意去贬低其它任何产品的意思。我更多的是想把一些新的技术思路拿出来和大家一起分享。我相信每种技术都有它的优点。所以希望大家一起探讨，纯技术的。
转载于:https://blog.51cto.com/c1813/685093
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
