博主語：關於郵件歸檔，很多人肯定都知道或者正在使用。但是真正理解歸檔的可能甚少。我也是知曉一二，卻不能詳細的闡述。偶從網上尋得此文，與各位共享。文中作者以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等工作。不過有意思的是它可以把滿足條件的郵件信 息，通過郵件的方式及時警告道管理員或者審計員。當然你別指望它會把它攔住，因爲歸檔系統都是事後諸葛。
好了，爲了寫這玩意兒都沒睡好覺。當然也非常感謝各位版主的鼓勵和支持。
這裏我想重申的是：我不想因爲我的帖子導致其他廠家的心裏不舒服，我沒有刻意去貶低其它任何產品的意思。我更多的是想把一些新的技術思路拿出來和大家一起分享。我相信每種技術都有它的優點。所以希望大家一起探討，純技術的。