軟件即服務(SaaS)應用程序的出發點是：與應用程序有關的一切都在云中，所以數據的維護、冗余和恢復均由SaaS提供商負責。但實際情況比較復雜，所以部署的大型SaaS環境中出現了值得關注的微妙之處。雖然本文關注的是Salesforce.com的應用程序，但汲取的經驗教訓可以運用于幾乎任何SaaS提供商�！　�

        數據庫基本知識

　　不妨先從基本方面即應用程序底層的數據庫聊起。為了確保服務連續性，幾乎任何SaaS提供商針對客戶數據都要有集群或復制策略。Salesforce.com持續不斷地復制用戶數據，其數據中心提供了相當高的冗余性。由于它采用了集群多租戶架構，所以備份和冗余服務相當復雜――而且它有許多工作要做。主生產環境集群可能不得不處理1萬個客戶和10萬個用戶的交易事務。

　　Salesforce.com在確保正常工作時間方面有著出色的記錄。

　　雖然SaaS應用程序中包含了免費的數據備份服務，但只有因提供商的失誤而需要恢復時，數據恢復服務才是免費的。如果客戶因自身的失誤而需要把數據恢復到某個歷史時間點，那么恢復這些數據需要另行收費�？紤]到隨時都有數量眾多的同步備份線程，找出三個星期前你數據記錄的歷史狀態面臨的復雜性也就可想而知了。

　　所以汲取的第一個經驗教訓就是，定期對你自己的數據進行備份。如果你的SaaS提供商有自動導出或存檔功能，可以把數據備份到本地文件存儲系統，就要使用該功能。要是沒有，可以使用高速數據裝載工具(data loader)。如果是客戶關系管理(CRM)系統，周六上午清晨進行全面的每周快照(snapshot)最穩妥;我們通常建議保留六個月的備份文件。別忘了制定一項策略來備份附件(以及對象模型中的附件指針)。

　　未雨綢繆

　　但問題可沒有這么簡單，因為勢必會出現這么種情況：你需要某些數據，但標準的導出工具卻忽視了這部分數據。你確實需要每個表中每個部分的數據，包括管理日志。比方說，由于一名滿腹牢騷的員工提出訴訟，我們的一個客戶正處于出示證據的階段。該客戶需要證明：這名員工每次都沒有按公司要求登錄進入到系統。整整兩年都是這樣!從SaaS提供商恢復這部分數據所需要的費用高得連律師都覺得不好意思。

　　此外，SaaS備份系統不會對系統的對象模型、元數據、定制元素、報表定義或你的代碼拍快照。 雖然這些數據不需要每個星期都進行備份，但為了便于配置控制，每個星期備份并沒有壞處。備份這些數據可能需要使用一些外部實用工具，通過應用程序的應用編程接口(API)來提取數據，不過這些實用工具通常是開源工具，不收費。

　　深入存檔

　　要考慮的下一個方面是存檔：從聯機系統刪除不活動或過時的記錄。之所以可能需要這么做，是由于貴公司的信息保留政策、性能問題(大型報表尤其如此)，或者需要降低存儲費用。我還沒有遇到過這種情形：整整七年一動也沒動的數據需要保留在CRM系統上;某些企業可能根本不需要再看到時間在兩年以上的數據。

　　但CRM數據根本不是簡單的數據庫;從系統刪除記錄會帶來復雜的后果。CRM數據庫包含的表在10個到200個之間――具體取決于提供商，用戶級對象可能會在表與表之間創建一些確實很有趣的指針。由于這個原因，絕對不能從系統刪除一些CRM對象。我們進一步建議，Account(客戶)和Opportunity(銷售機會)這兩類對象絕對不該刪除，因為它們是好多指針的核心。

　　進行存檔及從系統上刪除最容易的部分是處于指針樹上葉節點處的對象。比方說，對舊的附加文檔、電子郵件、筆記注釋和銷售線索進行存檔相當簡單。不過，進行存檔的整個意義在于能夠在需要時獲得相應數據!!!所以，確保每個存檔都含有一個“使用說明”文件，里面有說明如何存檔的核對一覽表。畢竟六個月過后，沒有人會記得如何拆開或解釋存檔庫中的數據。

　　至于對CRM系統來說比較核心的對象，進行存檔可能相當復雜。比方說，在Salesforce.com中合理存檔“Contacts”(聯系人)就需要提取10次，以及一系列必須按順序進行的刪除操作。

　　還有什么其他方法嗎？在許多情況下，隱藏不需要的數據比從系統實際刪除該數據來得容易。隱藏數據通常需要設置特殊的記錄類型值，以表明這是不活動的數據。這個策略的關鍵在于，確保所有視圖、報表、工作流、觸發閾值和外部接口都已經過了改動，以便把有標記的記錄排除在外。這聽上去可能很復雜，但如果借助適當的配置管理，這個方法還是要比對嵌入得最深的CRM數據　進行存檔來得簡單。