雷蒙布盧姆(Raymond Blum)領導著一支站點可靠性工程師團隊，主要負責谷歌數據的保密性和安全性。當然，谷歌永遠也不會透露那些數據的總量是多少，但是從其高管的言語中來看，那些數據總量沒達到YB級至少也達到了EB級。僅Gmail服務的相關數據就達到了EB級。
    布盧姆在解釋谷歌如何互聯網時稱，常規的備份策略在谷歌是行不通的，原因是：在一般情況下，它們會隨著容量進行調整。

他談到了以下要點：

從未出現過數據丟失的事故。即使在GMail服務宕機時也沒有丟失過數據，但是這比磁帶備份要復雜得多。 整個系統的各個地方都需要檢索數據，這就要求它在包括人在內的每一個層級上都提供引擎。

備份無用。它其實是你最關心的數據恢復功能。 它是一個恢復系統而不是備份系統。備份只是數據恢復戰略中的一部分內容。 將任務轉至備份，讓它具備所需的各種功能，以便將數據恢復工作盡可能地簡化。

你無法按比例調整。 如果數據量增加一百倍，你不可能將人力資源或機器資源也增加一百倍。你應該去尋找倍增器。 自動化是提高利用率和效率的重要方法之一。

無處不在的備用冗余。谷歌有很多種服務，總是會有某一些服務出現故障。這是不可避免的，就象人體內的細胞也在不停地老化死去一樣。 谷歌從未想過能夠避開這種情況，而是未雨綢繆地制定對應的計劃。

無處不在的多樣性問題。如果你擔心某個站點不完全，那就請把數據放到多個站點上儲存。 如果你擔心的問題是用戶誤操作，那就請設置各種隔離政策，對用戶互動進行限制。如果你想免于受到軟件漏洞的危害，那就請使用不同的軟件。 將數據保存在不同廠商的設備上可以減少軟件漏洞的危害性。

將人中整個工作流程中解放出來。Gmail保存了多少份電子郵件的副本? 人們不應該去關心這樣的問題。有些參數是由Gmail設置，然后由系統來管理的。 這是慣例。高級政策設置完成后，系統就會照此執行。 只有出現超常規的事情后，才需要人工介入。

用實際應用去證明它。如果你根本就不去嘗試，那么它肯定是無法正常工作的。 備份和恢復一直處于被測試狀態中，目的是驗證它們是否能夠正常運作。

不管是大型企業還是小型企業，都能從中學到不少知識。 布盧姆談到的那些內容既風趣，又有教益，非常值得一讀。他本人似乎也非常喜愛這項工作所具備的挑戰性。

以下是我個人獲得的一些心得：

數據有效性必須是100%。 永遠也不會出現數據丟失的情況。

從統計學的角度來說，如果你在一個2GB的文件中丟掉200K的數據，那可能并不是很多，但是那份文件可能就變得不能用了。

數據有效性比訪問通道有效性重要得多。如果一個系統宕機了，情況并不會變得十分糟糕。 但是如果數據丟失了，那就非常糟糕了。

谷歌保證你會遇到下列情況的各種組合：

場地隔離

因應用層出現問題導致的隔離

因存儲層出現問題導致的隔離

因媒體失效導致的隔離

你必須考慮到你能控制的范圍。將軟件標在縱軸上，地點標在橫軸上。 如果你想覆蓋所有的東西，你就需要在每個不同地點都保留一份軟件層的副本。你可以在不同地點使用虛擬機來實現這個目標。

備用冗余與可恢復性并不是一回事。

保留再多的數據副本也不能保證不發生數據丟失的事故。

對于某些類型的宕機事故來說，保留很多份數據副本確實是有用的。如果一顆流星撞擊了一個數據中心，而你在遠程站點保留了數據副本，那你當然不會受到影響。

如果你的存儲設備中有一個軟件漏洞，那么將數據復制到再多的設備上也無濟于事，因為所有的數據副本都存在那個漏洞。Gmail宕機就是最好的例子。

數據中心遭流星撞擊的概率絕不會比軟件漏洞、用戶誤操作或錯誤數據寫入等情況出現的概率高。

備用冗余非常適用于局部引用。當你希望所有的數據引用盡可能接近數據被使用的地點時，復制是個很好的方法。

整個系統的實用性達到了驚人的程度。

谷歌有很多種服務，總是會有某一些服務出現故障，這是不可避免的。 就象人體內的細胞在不斷地死亡一樣。我們從未想過實現服務從不出現故障的目標。 我們為它制定預案計劃。各種設備總是會出現故障。

備用冗余就是解決問題的方法。事實證明，多臺設備的可靠性比一臺優質設備的可靠性更高。 一臺設備可能會因為某種災難而被毀掉。但是存放在50個不同地點的很多臺設備是很難在同一時間一起被毀掉的。

大規模并行系統出現數據丟失的概率更高。