# Google 如何備份 Internet 和數十億字節的其他數據 > 原文： [http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html)  [Raymond Blum](https://plus.google.com/115038404694487056892/posts?hl=en) 領導了一組站點可靠性工程師，負責對 Google 的數據保密并確保其安全。 當然，Google 永遠不會說這實際上有多少數據，但是從評論看來，它還不是 [約字節](http://en.wikipedia.org/wiki/Yottabyte) ，但很多 [艾字節](http://en.wikipedia.org/wiki/Exabyte) 大小。 僅 GMail 就要處理近幾十億字節的數據。 Blum 先生在視頻中 [Google 如何備份互聯網](http://www.youtube.com/watch?v=eNliOm9NtCM) 解釋了常見的備份策略不適用于 Google 原因：通常他們以容量 擴展規模 **。 如果備份兩倍的數據需要兩倍的工作量（時間，精力，空間等），那么它將無法正常工作，并且無法擴展。 您必須找到效率，以便容量可以比支持該容量所需的努力更快地擴展。 從備份一個 EB 備份到備份兩個 EB 時，需要一個不同的計劃。 談論主要是關于 Google 如何做到這一點。** 演講的一些主要主題： * **從來沒有數據丟失** 。 即使是臭名昭著的 GMail 中斷也沒有丟失數據，但是故事遠不只是大量的磁帶備份而復雜。 從整個堆棧中檢索數據，這需要在各個層面（包括人員）進行工程設計。 * **備份無用**。 這是您關心的還原。 這是一個還原系統，而不是備份系統。 備份是您為還原的奢侈而支付的一種稅。 將工作轉移到備份上，并根據需要使其變得復雜，以使還原如此簡單，一只貓就可以做到。 * **您無法線性縮放**。 您無法擁有 100 倍的數據或 100 倍的人員或機器資源。 尋找力的乘數。 自動化是提高利用率和效率的主要方法。 * **冗余**。 Google 的東西總是失敗。 廢話 人體細胞死亡的方式相同。 Google 并不夢想事情不會消亡。 它計劃。 * **所有事物的多樣性** 。 如果您擔心站點的位置，請將數據放在多個站點中。 如果您擔心用戶錯誤，請與用戶交互隔離。 如果要防止軟件錯誤，請把它放在其他軟件上。 將東西存儲在不同的供應商設備上，以減少大的供應商錯誤影響。 * **將人類帶出循環** 。 GMail 保留多少電子郵件副本？ 這不是人類應該關心的事情。 一些參數是由 GMail 配置的，系統會處理。 這是一個不變的主題。 制定了高級策略，系統也這樣做了。 如果發生超出規范的事情，只會打擾到人。 * **證明** 。 如果您不嘗試，將無法使用。 不斷測試備份和還原，以驗證它們是否有效。 對于任何規模的組織，這里都有很多值得學習的地方。 布拉姆先生的 [演講](http://www.youtube.com/watch?v=eNliOm9NtCM) 具有娛樂性，內容豐富，值得一看。 他似乎確實很喜歡工作中的挑戰。 這是我對這個非常有趣的演講的掩飾，我們從野獸內部學習了許多秘密： * **數據可用性必須為 100％ 。** **從來沒有數據丟失**。 * 從統計上講，如果您從 2GB 的文件中丟失了 200K，這聽起來不錯，但是該文件現在可能已無用，請考慮執行文件或納稅申報單。 * 數據的可用性對訪問的可用性更為重要。 如果系統出現故障，那不是世界末日。 如果數據丟失，那就是。 * Google 保證在所有可能的組合中為您提供以下所有服務： * 位置隔離 * 與應用層問題的隔離 * 與存儲層問題的隔離 * 與媒體故障隔離 * **考慮可以在** 上移動滑塊的尺寸。 將軟件垂直放置，水平放置。 如果要涵蓋所有內容，則需要在不同位置復制該軟件層。 您可以在不同位置的 VM 上執行此操作。 * **冗余與可恢復性** 不同。 * 多份復印無助于達到無損保證。 * 許多副本對某些類型的中斷有效。 如果小行星撞擊數據中心，并且您的副本很遠，您就會被覆蓋。 * 如果存儲堆棧中有錯誤，則復制到 N 個位置無濟于事，因為該錯誤會損壞所有副本。 以 GMail 中斷為例。 * 小行星的數量不及代碼錯誤，用戶錯誤或緩沖區寫入錯誤。 * 冗余有利于參考位置。 當您希望所有數據引用都盡可能靠近使用數據的位置時，復制就很好。 * **整個系統非常強大，因為其中有很多**。 * **Google 內容始終失敗**。 廢話 人體細胞死亡的方式相同。 我們沒有夢想事情不會消亡。 我們為它計劃。 機器一直死掉。 * **冗余就是答案** 。 總的來說，結果比一臺高質量機器更可靠。 一架機器可以被小行星摧毀。 放置在 50 個不同位置的機器更難銷毀。 * **大規模并行系統有更多的損失機會** 。 * 可以在 30K 臺計算機上運行的 MapReduce 非常棒，直到出現錯誤為止。 您有相同的錯誤等待立即在任何地方運行，從而擴大了影響。 * **本地副本無法防止站點中斷** 。 * 如果服務器機房中有洪災，RAID 將無濟于事。 * 大約一年前，在整個 Google 上使用的 Google 文件系統（GFS）將 RAID 的概念提升了一個檔次。 使用 [編碼技術](http://en.wikipedia.org/wiki/Erasure_code) 一次寫入不同城市中的多個數據中心，因此您只需要 N-1 個片段即可重建數據。 因此，有了三個數據中心，一次就可以消亡，您仍然可以獲得可用的數據。 * **可用性和完整性是組織范圍內的特征** 。 * Google 工程師，BigTable，GFS，Colossus 都知道數據持久性和完整性是第一要務。 有很多系統可以檢查和糾正數據可用性和完整性方面的任何失誤。 * **您想要所有事物的多樣性** 。 * 如果您擔心站點的位置，請將數據放在多個站點中。 * 如果您擔心用戶錯誤，請與用戶交互隔離。 * 如果要防止軟件錯誤，請將其放在其他軟件上。 將東西存儲在不同的供應商設備上，以減少大的供應商錯誤影響。 * **用來備份內容的磁帶確實非常好** 。 * **磁帶很棒，因為它不是磁盤** 。 如果可以的話，他們會使用打孔卡。 * 想象一下您是否在 SATA 磁盤的設備驅動程序中存在錯誤。 磁帶可以幫助您避免麻煩。 因為不同的媒體意味著不同的軟件，所以它增加了您的多樣性。 * 磁帶容量遵循摩爾定律，因此盡管他們正在研究替代方案，但他們對磁帶作為備份介質感到非常滿意，但他們不會說它們是什么。 * 磁帶已加密，這意味著邪惡力量很難從中獲得有用的東西。 * **備份無用。 這是您關心的** 還原。 * 在有人需要數據之前先確定是否存在問題。 當您需要還原時，您確實需要它。 * **運行連續還原** 。 不斷隨機選擇 5％的備份并還原它們以進行比較。 為什么？ 在數據丟失之前找出備份是否有效。 抓了很多問題。 * **運行自動比較** 。 由于原件已更改，因此無法與原件進行比較。 因此，對所有內容進行校驗和并比較校驗和。 將其返回到源介質，磁盤或閃存，或它來自何處。 確保數據可以往返。 這一直都在做。 * **出現故障率變化的警報** 。 * **如果有所不同，您可能想了解一下** 。 如果一切正常，請不要告訴我。 * 可能會出現一些故障，但不要針對第一次嘗試后無法還原的文件發出警報。 * 假設第一次嘗試的失敗率通常是 N。第二次嘗試的失敗率是 Y。如果失敗率發生變化，則說明出現了問題。 * **一切都破裂了** 。 * 磁盤一直損壞，但是您知道它發生的時間，因為您正在監視它。 * 使用磁帶之前，您不知道它已損壞，直到嘗試使用它為止。 磁帶可以使用很長時間，但是您需要先對其進行測試。 * 磁帶 上的 **[RAID4](http://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_4) 。** * 不要只寫一盤磁帶。 它們是墨盒。 機器人可能會掉落它們，或者可能會產生一些磁通量。 不要碰碰運氣 * 寫入磁帶 **時，告訴編寫者保留數據** ，直到可以更改為止。 如果這樣做，您就違反了合同。 * 建立 4 個完整的磁帶，然后通過將所有內容異或來生成第 5 個代碼帶。 您可以丟失 5 盤磁帶中的任何一盤并恢復數據。 * 現在告訴編寫者他們可以更改源數據，因為數據已經將其移到了最終的物理位置，并且現在是冗余的。 * Google 備份的每一位數據都經過此過程。 * 一個月會丟失數百個磁帶，但是由于這個過程，每月不會有數百個數據丟失案例。 * 如果丟失了一條磁帶，則可以使用連續還原檢測到該磁帶，并使用同級磁帶重建另一條磁帶，一切正常。 在極少的情況下，如果兩個磁帶都損壞，則只有在磁帶上的相同兩個點都損壞的情況下，數據才會丟失，因此在磁帶級進行重建。 * 由于這些技術，不會造成數據丟失。 這很昂貴，但這是做生意的成本。 * **備份是您為還原**所支付的奢侈稅。 * **這是一個還原系統，而不是備份系統** 。 恢復是不可屏蔽的中斷。 他們勝過一切。 恢復備份。 * 使備份變得復雜并且需要的時間很長。 使恢復盡可能快和自動。 * 恢復應該是愚蠢的，快速且簡單的。 希望一只貓能夠觸發集中還原。 * 當您休息好或狗累了時，恢復可能會發生。 因此，您不希望人為因素決定還原服務數據副本是否成功。 你壓力很大。 因此，在進行備份的所有時間中，所有工作和思考都要做。 * 大量系統以這種方式工作。 * 數據源可能必須能夠存儲一段時間（也許幾天），然后才能保證已備份數據。 但是一旦備份，便可以快速還原和還原。 * 不再最有效地利用備份上的介質來加快還原速度。 花兩個小時讀磁帶是不好的。 只寫一半的磁帶并并行讀取它們，這樣您就可以在一半的時間內取回數據。 * **秤是一個問題** 。 * 當您有 EB 級數據時，會有現實世界的限制。 如果您必須復制 10 EB，那么每天備份數據可能需要 10 周的時間。 * 在全球的數據中心中，您有幾種選擇。 您是否給每個站點近乎無限的備份能力？ 您是否按地區對所有備份進行群集？ 運送數據的帶寬呢？ 您不需要帶寬來賺錢嗎？ * 查看相關費用。 有妥協。 并非每個站點都具有備份功能。 必須平衡網絡上的可用容量。 您從哪里獲得最大的收益。 例如，備份必須在站點 X 上進行，因為它具有帶寬。 * **您無法線性縮放**。 * 不能只是說您想要更多的網絡帶寬和更多的磁帶驅動器。 驅動器損壞，因此，如果驅動器數量為 10,000，則需要的操作員數量是驅動器數量的 10,000 倍。 您是否有 10,000 倍的裝載臺來放置磁帶驅動器，直到卡車將其撿起。 這些都不是線性的。 * 盡管磁帶庫的數量增加了一個完整的數量級，但涉及的人數卻沒有 10 倍。 還有更多的數字，但遠非線性增長。 * 例子是一個早期的預測，隨著電話數量的增長，美國人口的 30％將被用作電話接線員。 他們看不到的是自動切換。 * **自動化所有** 。 * 調度是自動的。 如果您有一項服務，則說我有一個數據存儲，并且每個 N 都需要一個副本，并且還原必須在 M 中進行。在內部，系統會做到這一點。 計劃備份，運行還原測試以及運行完整性測試等。當檢測到損壞的磁帶時，將自動對其進行處理。 * 您作為人類沒有看到任何這些。 您可能有一天會問平均多少磁帶斷裂。 否則，如果磁帶損壞率從每天 100 條磁帶更改為每天 300 條磁帶，可能會發出警報。 但是在此之前，請不要告訴我每天是否有 100 盤磁帶破損，如果這超出了正常范圍。 * **人體不應參與穩態操作** 。 * 包裝和運輸驅動器仍然是人類的活動。 自動化的界面可以準備運輸標簽，獲取 RMA 編號，檢查包裹是否已外出，獲得收據確認，以及是否發生這種情況，必須由人工干預。 * **庫軟件維護同樣** 。 如果要進行固件更新，則不會有人在每個系統上運行并執行升級。 下載它。 讓它推送到金絲雀圖書館。 讓它進行測試。 讓結果驗證為準確。 然后將其推出。 沒有人參與正常操作。 * **自動處理機器死亡** 。 * 機器每分鐘死兩次。 如果一臺機器在使用 30,000 臺機器的 MapReduce 工作中快要死了，請不要告訴我，只需處理并繼續前進即可。 查找另一臺機器，移動工作，然后重新啟動。 * **如果存在依賴項，則安排等待時間**。 如果您等待太久，請告訴我。 您可以自己安排時間。 這是算法的工作，而不是人類的工作。 * **隨著增長不斷提高效率** 。 * 大大提高了利用率和效率。 不能有 100 倍的數據需要 100 倍的人員或機器資源。 * **2011 年的重大 GMail 中斷和恢復** 。 關于 Google 如何刪除數據并取回數據的故事。 * 在星期日的上午 10:31，他得到了一個頁面，上面寫著“ Holly Crap call xxx-xxxx”。 有關中斷的更多信息 [此處](http://gmailblog.blogspot.com/2011/02/gmail-back-soon-for-everyone.html) 。 * Gmail 的數據量已接近 EB。 磁帶很多。 * 100％恢復。 可用性不是 100％。 在第一天或第二天還沒有全部。 但是到了一段時期的盡頭。 * 在復制發生的層中發生了一系列的錯誤和不幸。 是的，我們有三個相同的文件，但它們都是空的。 即使進行單元測試，系統測試和集成測試，錯誤也可以解決。 * 從磁帶恢復。 大量工作。 這是恢復時間與規模有關的地方。 取回千兆字節可以在幾毫秒到幾秒鐘內完成。 取回 200,000 個各個演出的收件箱將需要一段時間。 * 在歐洲喚醒了幾個同事，因為他們比較新鮮。 分布式勞動力的優勢。 * 已從許多磁帶上還原了數據并進行了驗證。 沒花幾個星期或幾個月，只花了幾天。 他們對此感到滿意。 其他處于類似情況的公司花了一個月的時間才意識到他們無法取回數據。 已采取步驟來確保下一次該過程將更快。 * 一個磁帶機需要 2 個小時才能讀取。 磁帶遍布各處。 否則，任何一個位置都將沒有足夠的能力來讀取還原過程中涉及的所有磁帶。 * 使用壓縮和校驗和，他們實際上不需要讀取 200K 磁帶。 * 從那時起，恢復流程已得到很大改善。 * **優先還原** 。 * 可以在保存更重要的數據（例如當前收件箱和發送的電子郵件）之后恢復已存檔的數據。 * 一個月內沒有被觸摸過的帳戶可以等待，直到更活躍的用戶被首先還原。 * **備用系統被視為巨大的全球生物** 。 * 不想僅在紐約進行 GMail 備份，因為如果該數據中心增長或收縮，則備份需要適當擴展。 * 將備份視為一個巨大的全球跨越系統。 進行備份時，它可能完全位于其他位置。 * 必須在磁帶所在的位置進行磁帶還原。 但是在制作磁帶之前，數據可能在紐約，而備份在俄勒岡州，因為那里有足夠的存儲空間。 位置隔離是自動處理的，不會告訴客戶端其數據備份的位置。 * 容量可以移動。 只要具有全球容量并且網絡可以支持它，磁帶位于何處都沒有關系。 * **您擁有的數據越多，保留它就越重要** 。 * 通常，越大的東西越重要。 Google 過去只是搜索。 現在是 Gmail，存儲在驅動器，文檔等中的東西。它既更大，也越來越重要。 * **擁有良好的基礎架構** 。 * 可以使用通用的瑞士軍刀真的很不錯。 編寫 MapReduce 時，他們可能從未想到過將其用于備份。 但是，如果沒有 MapReduce，就不可能出現將其用于備份的想法。 * **縮放比例確實很重要，您無法擁有任何無法擴展的部分-軟件，基礎架構，硬件，流程-**。 * 您不能說我將在擁有操作人員的情況下部署更多的磁帶機。 如果您要雇用兩倍的人，您有兩倍的停車位嗎？ 自助餐廳的房間？ 洗手間？ 一切都必須擴大規模。 您將遇到一個瓶頸，它將阻止您。 * **證明** 。 * 不要將任何事情視為理所當然。 希望不是戰略。 * 如果不嘗試，將無法使用。 必須進行還原才能驗證備份。 直到最后，您還沒有證明任何東西。 這種態度發現了很多失敗。 * **DRT。 災難恢復測試** 。 * 每 N 個月就會發布一次災難場景。 模擬組織各個級別的響應。 * 在災難不帶走任何損失的情況下，公司將如何生存？ 必須學會適應。 * 發現基礎結構和物理安全方面的巨大漏洞。 * 想象一下，一個數據中心有一條通向它的道路，并且有卡車在路上裝載著備用發電機的燃料。 路迷路了怎么辦？ 最好有一條道路和另一家柴油燃料供應商。 * 確實有供應鏈冗余策略。 * **在不同時間點在不同位置的不同軟件堆棧中的冗余** 。 * **不要只讓數據在堆棧中遷移** 。 將數據保留在堆棧的不同層中一段特定的駐留時間。 因此，如果您丟失了該數據，則此數據會重疊。 時間，位置和軟件。 * 考慮 GMail 中斷示例。 如果復制損壞了，怎么也不會丟失數據？ 這是聽眾提出的問題，他真的不想透露細節。 數據一直在備份。 假設我們有截至 9PM 的數據。 假設損壞發生在晚上 8 點，但尚未錄制到磁帶上。 腐敗被制止了。 軟件已回滾到工作版本。 在堆棧中的某個時刻，所有數據仍然存在。 磁帶上有東西。 有東西正在復制。 前端有東西。 日志中有東西。 所有這些來源都有重疊之處，有可能重建所有數據。 對于這種情況，政策是直到將數據放入另一個堆棧中 N 個小時后，才從一個卡住的數據中取出數據。 * **刪除問題** 。 * 我要刪除它。 不會為了刪除數據而重寫磁帶。 大規模而言太昂貴了。 * 一種方法是對加密密鑰進行智能處理。 他沒有告訴我們 Google 做什么。 也許丟失了有效刪除數據的密鑰？ * **當您信任同事并分擔責任時，一個龐大的組織就可以工作。** 。 * 相信他們了解自己的部分。 * 確保組織和軟件接口定義正確。 在各層之間實施驗證測試。 * **白名單和黑名單**。 * 確保數據位于保證的位置，并保證不在某個位置，這與其余的哲學原理（即位置多樣性和位置獨立性）背道而馳。 * 最初不是堆棧的功能。 必須添加以支持政府要求。 * 在堆棧中將責任降低得越低越好。 填寫正確的個人資料，它就會神奇地發生。 ## 相關文章 * [在 Reddit 上](http://www.reddit.com/r/programming/comments/1wzsmk/how_google_backs_up_the_internet_along_with/) “如果您想對軟件錯誤進行“保護”，那么？？？ 嘿托德， 這是一個令人難以置信的帖子，其中包含許多有用的信息，非常感謝您將其組合在一起！ 嘿， 我想知道更多有關 Google 備份的內容。 是完整的檔案備份，以便保存在 google 中創建的每個文件，還是更多的滾動備份，其中刪除了未使用的數據，僅備份了最近的幾周。 另外，是 Google 對數據進行重復數據刪除，還是每個用戶的每個文件等等，都是單獨保存的。 呵呵，所以安全是一個問題。 這是我在網上找到的最佳信息之一，謝謝分享