雖然郵箱歸檔是很常見技術，但是並非每個人對該技術有很完整系統的理解，下面這篇文章希望能幫助大家對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%的性能消耗了。