雷蒙布盧姆(Raymond Blum)領(lǐng)導著一支站點可靠性工程師團隊，主要負責谷歌數(shù)據(jù)的保密性和安全性。當然，谷歌永遠也不會透露那些數(shù)據(jù)的總量是多少，但是從其高管的言語中來看，那些數(shù)據(jù)總量沒達到Y(jié)B級至少也達到了EB級。僅Gmail服務的相關(guān)數(shù)據(jù)就達到了EB級。
布盧姆在解釋谷歌如何互聯(lián)網(wǎng)時稱，常規(guī)的備份策略在谷歌是行不通的，原因是：在一般情況下，它們會隨著容量進行調(diào)整。
他談到了以下要點：
· 從未出現(xiàn)過數(shù)據(jù)丟失的事故。即使在GMail服務宕機時也沒有丟失過數(shù)據(jù)，但是這比磁帶備份要復雜得多。 整個系統(tǒng)的各個地方都需要檢索數(shù)據(jù)，這就要求它在包括人在內(nèi)的每一個層級上都提供引擎。
· 備份無用。它其實是你最關(guān)心的數(shù)據(jù)恢復功能。 它是一個恢復系統(tǒng)而不是備份系統(tǒng)。備份只是數(shù)據(jù)恢復戰(zhàn)略中的一部分內(nèi)容。 將任務轉(zhuǎn)至備份，讓它具備所需的各種功能，以便將數(shù)據(jù)恢復工作盡可能地簡化。
· 你無法按比例調(diào)整。 如果數(shù)據(jù)量增加一百倍，你不可能將人力資源或機器資源也增加一百倍。你應該去尋找倍增器。 自動化是提高利用率和效率的重要方法之一。
· 無處不在的備用冗余。谷歌有很多種服務，總是會有某一些服務出現(xiàn)故障。 這是不可避免的，就象人體內(nèi)的細胞也在不停地老化死去一樣。 谷歌從未想過能夠避開這種情況，而是未雨綢繆地制定對應的計劃。
· 無處不在的多樣性問題。如果你擔心某個站點不完全，那就請把數(shù)據(jù)放到多個站點上儲存。 如果你擔心的問題是用戶誤操作，那就請設(shè)置各種隔離政策，對用戶互動進行限制。如果你想免于受到軟件漏洞的危害，那就請使用不同的軟件。 將數(shù)據(jù)保存在不同廠商的設(shè)備上可以減少軟件漏洞的危害性。
· 將人中整個工作流程中解放出來。Gmail保存了多少份電子郵件的副本？人們不應該去關(guān)心這樣的問題。有些參數(shù)是由Gmail設(shè)置，然后由系統(tǒng)來管理的。 這是慣例。高級政策設(shè)置完成后，系統(tǒng)就會照此執(zhí)行。 只有出現(xiàn)超常規(guī)的事情后，才需要人工介入。
· 用實際應用去證明它。如果你根本就不去嘗試，那么它肯定是無法正常工作的。 備份和恢復一直處于被測試狀態(tài)中，目的是驗證它們是否能夠正常運作。
不管是大型企業(yè)還是小型企業(yè)，都能從中學到不少知識。 布盧姆談到的那些內(nèi)容既風趣，又有教益，非常值得一讀。他本人似乎也非常喜愛這項工作所具備的挑戰(zhàn)性。
以下是我個人獲得的一些心得：
· 數(shù)據(jù)有效性必須是100%。 永遠也不會出現(xiàn)數(shù)據(jù)丟失的情況。
o 從統(tǒng)計學的角度來說，如果你在一個2GB的文件中丟掉200K的數(shù)據(jù)，那可能并不是很多，但是那份文件可能就變得不能用了。
o 數(shù)據(jù)有效性比訪問通道有效性重要得多。如果一個系統(tǒng)宕機了，情況并不會變得十分糟糕。 但是如果數(shù)據(jù)丟失了，那就非常糟糕了。
o 谷歌保證你會遇到下列情況的各種組合：
§ 場地隔離
§ 因應用層出現(xiàn)問題導致的隔離
§ 因存儲層出現(xiàn)問題導致的隔離
§ 因媒體失效導致的隔離
o 你必須考慮到你能控制的范圍。將軟件標在縱軸上，地點標在橫軸上。 如果你想覆蓋所有的東西，你就需要在每個不同地點都保留一份軟件層的副本。你可以在不同地點使用虛擬機來實現(xiàn)這個目標。
· 備用冗余與可恢復性并不是一回事。
o 保留再多的數(shù)據(jù)副本也不能保證不發(fā)生數(shù)據(jù)丟失的事故。
o 對于某些類型的宕機事故來說，保留很多份數(shù)據(jù)副本確實是有用的。如果一顆流星撞擊了一個數(shù)據(jù)中心，而你在遠程站點保留了數(shù)據(jù)副本，那你當然不會受到影響。
o 如果你的存儲設(shè)備中有一個軟件漏洞，那么將數(shù)據(jù)復制到再多的設(shè)備上也無濟于事，因為所有的數(shù)據(jù)副本都存在那個漏洞。Gmail宕機就是最好的例子。
o 數(shù)據(jù)中心遭流星撞擊的概率絕不會比軟件漏洞、用戶誤操作或錯誤數(shù)據(jù)寫入等情況出現(xiàn)的概率高。
o 備用冗余非常適用于局部引用。當你希望所有的數(shù)據(jù)引用盡可能接近數(shù)據(jù)被使用的地點時，復制是個很好的方法。
· 整個系統(tǒng)的實用性達到了驚人的程度。
o 谷歌有很多種服務，總是會有某一些服務出現(xiàn)故障，這是不可避免的。 就象人體內(nèi)的細胞在不斷地死亡一樣。我們從未想過實現(xiàn)服務從不出現(xiàn)故障的目標。 我們?yōu)樗贫A案計劃。各種設(shè)備總是會出現(xiàn)故障。
o 備用冗余就是解決問題的方法。事實證明，多臺設(shè)備的可靠性比一臺優(yōu)質(zhì)設(shè)備的可靠性更高。 一臺設(shè)備可能會因為某種災難而被毀掉。但是存放在50個不同地點的很多臺設(shè)備是很難在同一時間一起被毀掉的。
· 大規(guī)模并行系統(tǒng)出現(xiàn)數(shù)據(jù)丟失的概率更高。
o 如果沒有漏洞的話，MapReduce在3萬臺設(shè)備上運行還是不錯的。但是如果系統(tǒng)有漏洞的話，那后果立刻就會被放大無數(shù)倍。
· 如果整個站點出現(xiàn)宕機，那么即便有本地數(shù)據(jù)副本也無濟于事。
o 如果你的服務器機房進水了，那么即便你使用了RAID也沒用。
o 谷歌直到一年前才停止使用的Google File System（GFS）系統(tǒng)充分發(fā)揮了RAID的概念。利用編碼技術(shù)同時向不同城市的多個數(shù)據(jù)中心寫入數(shù)據(jù)，因此你只要一些碎片就能完成數(shù)據(jù)的重建工作。 因此，即便3個數(shù)據(jù)中心同時熄火，你仍然能夠使用自己的數(shù)據(jù)。
· 有效性和完整性都是整個機構(gòu)的特征。
o 谷歌工程師、BigTable、GFS、Colossus都知道保證數(shù)據(jù)耐用性和完整性是首要大事。現(xiàn)在有很多系統(tǒng)就是用來檢查和糾正數(shù)據(jù)有效性和完整性方面的錯誤的。
· 你想要多樣化的配置。
o 如果你擔心站點問題，請把數(shù)據(jù)存放到多個站點。
o 如果你擔心用戶人為誤差問題，請禁止用戶人工操作。
o 如果你想讓數(shù)據(jù)不受軟件錯誤的影響，就請把它放到不同的軟件中。將數(shù)據(jù)保存到不同廠商的設(shè)備上可以降低大廠商故障的影響。
· 利用磁帶將數(shù)據(jù)備份起來真的非常好。
o 磁帶其實很好用，因為它跟磁盤不一樣。如果可以的話，他們可能還會使用打孔卡片來儲存數(shù)據(jù)。
o 試想一下，如果你的SATA硬盤的設(shè)備驅(qū)動程序中出現(xiàn)了一個漏洞，會出現(xiàn)什么樣的后果呢？如果使用磁帶的話，就不會有這樣的問題了。 它增加了你的多樣性，因為不同的媒體需要使用不同的軟件。
o 磁帶容量符合摩爾法則的規(guī)定，因此將磁帶當作備份媒介來使用是很不錯的，即便它們能夠在其他設(shè)備上使用，它們也不會泄密。
o 磁帶是加密的，這就意味著壞人很難從中得到有用的東西。
· 備份是無用的。你關(guān)心的其實是數(shù)據(jù)修復問題。
o 如果系統(tǒng)存在問題的話，你就必須在用戶使用數(shù)據(jù)前找出它們。當你需要修復數(shù)據(jù)時，你就需要用到它了。
o 持續(xù)不斷地進行數(shù)據(jù)修復。隨機選擇5%的數(shù)據(jù)進行備份，然后修復數(shù)據(jù)并進行對比。 為什么呢？ 在數(shù)據(jù)丟失前，搞清楚備份系統(tǒng)是否工作正常。這樣可以找出并解決很多的問題。
o 進行自動對比。不能跟原始數(shù)據(jù)進行對比，因為原始數(shù)據(jù)已經(jīng)發(fā)生了變化。 因此，給所有的數(shù)據(jù)分配檢驗數(shù)字，然后對比那些檢驗數(shù)字。將數(shù)據(jù)放回源媒體、磁盤、閃存或是其他任何存儲媒介。 確定數(shù)據(jù)能夠環(huán)行一周再回來。這個過程一直在進行之中。
· 如果故障率出現(xiàn)變化，就發(fā)出警報。
o 如果有些東西發(fā)生了變化，你可能想知道到底是怎么回事。如果一切運行正常，那就別來煩我。
o 系統(tǒng)肯定會不時出現(xiàn)一些故障，但是如果只是某個文件在首次修復時出現(xiàn)問題，那就不用發(fā)警報了。
o 假設(shè)第一次出現(xiàn)故障的概率為N，第二次出現(xiàn)故障的概率為Y。 如果故障率出現(xiàn)了變化，那么肯定是哪里出錯了。
· 一切都停止下來。
o 磁盤經(jīng)常因為故障而停止工作，但是這種事情一發(fā)生你就會知道，因為你一直監(jiān)控著磁盤。
o 如果使用磁帶的話，那出現(xiàn)故障時你是不知道的，只有當你想去使用它時才會知道它出現(xiàn)了故障。磁帶可以存放很長的時間，但是在你需要用到它之前，你需要先進行測試。
· 磁帶上的RAID4。
o 不要將數(shù)據(jù)只寫到一盤磁帶上。它們都是盒式磁帶。 機械臂也許會失手掉落磁帶，磁帶上的磁粉也許會掉。不要冒險。
o 當把數(shù)據(jù)寫到磁帶上的時候，告訴寫入軟件將數(shù)據(jù)保存好，知道我們發(fā)出它可以改變的命令。如果你這樣做的話，你已經(jīng)違約了。
o 寫滿4盒磁帶后，通過XORing即可生成第五盤代碼磁帶。這5盒磁帶中丟掉任何一盤磁帶，你都依然可以恢復數(shù)據(jù)。
o 現(xiàn)在告訴寫入程序它們可以改變源數(shù)據(jù)了，因為數(shù)據(jù)已經(jīng)被存放到最終的位置上，現(xiàn)在那些源數(shù)據(jù)變成備份冗余副本了。
o 谷歌備份的每一點數(shù)據(jù)都要經(jīng)過這種處理。
o 每月丟失的磁帶可能達到數(shù)百盒，但是由于這個處理程序的關(guān)系，每個月的數(shù)據(jù)丟失事故并不會達到數(shù)百次。
o 如果一盒磁帶丟失了，可以利用持續(xù)不斷的數(shù)據(jù)修復檢測出來，然后你就可以利用相關(guān)的磁帶重新制作一盒與丟失的磁帶一模一樣的磁帶，所有的數(shù)據(jù)就都恢復了。如果碰巧遇到兩盒磁帶都損壞的情況，那只有當那兩盒磁帶的損壞點也是一樣的時候，你才會丟失數(shù)據(jù)，你可以利用磁帶重新恢復數(shù)據(jù)。
o 不要因為這些技術(shù)而令數(shù)據(jù)丟失。數(shù)據(jù)丟失的代價太大了，但這就是商業(yè)成本。
· 備份是你為避免發(fā)生數(shù)據(jù)修復成本而采取的預防措施。
o 它是一個數(shù)據(jù)修復系統(tǒng)而不是備份系統(tǒng)。數(shù)據(jù)修復是不可避免的中斷。 它們非常有用。利用備份來恢復數(shù)據(jù)。
o 按照要求對數(shù)據(jù)進行備份并根據(jù)需要將它們保留足夠長的時間。盡可能快和盡可能自動去進行數(shù)據(jù)修復。
o 數(shù)據(jù)修復操作應該是簡單、迅速和快捷的。你應該能夠通過一項簡單的操作來啟動數(shù)據(jù)修復。
o 數(shù)據(jù)修復工作可以在你休息或睡覺的時候進行。因此，最好不要在數(shù)據(jù)修復操作中添加任何人工操作的要素。 你承受著壓力。因此，當你在備份數(shù)據(jù)時請把數(shù)據(jù)修復的準備工作也做充足。
o 很大一部分系統(tǒng)都是這樣工作的。
o 數(shù)據(jù)源也許必須將數(shù)據(jù)保存一段時間，這段時間也許是幾天，然后才能將那些數(shù)據(jù)備份。但是一旦數(shù)據(jù)被備份好，它應該能夠迅速被恢復。
o 為了讓數(shù)據(jù)修復的速度盡可能快一點，請不要頻繁使用備份媒體。花兩個小時的時間去讀一盒磁帶的做法是不可取的。 只將一盒磁帶寫一半，然后同時讀取兩盒磁帶，這樣你就可以將數(shù)據(jù)恢復的時間縮短一半。
· 調(diào)整是一個問題。
o 當你有EB級的數(shù)據(jù)需要備份時，現(xiàn)實中還有其他一些限制條件。如果你必須拷貝10份EB級的數(shù)據(jù)，那你可能需要10個星期的時間去備份每天的數(shù)據(jù)。
o 由于數(shù)據(jù)中心遍布全球各地，因此你還有一些選擇的余地。你是否會給每一個站點分配近乎無限的備份容量？ 你是否會按地區(qū)將所有的備份數(shù)據(jù)集合在一起？ 傳輸數(shù)據(jù)的帶寬如何？ 你難道不需要為業(yè)務流量預留帶寬嗎？
o 相關(guān)成本。這里有很多折中方案。 并不是每一個站點都有備份設(shè)施。必須保證網(wǎng)絡(luò)上的可用容量處于均衡狀態(tài)。 備份必須在X站點進行，因為它有所需的帶寬。
· 你不可能成比例地調(diào)整規(guī)模。
o 不能說你想要多少網(wǎng)絡(luò)帶寬和磁帶都行。磁盤會出現(xiàn)故障，因此如果你有1萬塊磁盤的話，你可能需要1萬多名操作員去更換它們。 你有1萬個裝載支架來放磁帶嗎？這都不是成比例增加的。
o 雖然磁帶庫的數(shù)量已經(jīng)上升了一個數(shù)量級，但是對人員數(shù)量的要求并沒有同步提高10倍。需要的人數(shù)肯定會增加一些，但肯定不會象按比例增加那么多。
o 有一個例子可以說明這一點，早期人們曾預測電話數(shù)量會增加30%，那么話務員的數(shù)量也應該增加30%，但是事實上并非如此，因為后來使用了程控技術(shù)自動接線。
· 自動化技術(shù)
o 日程安排已經(jīng)實現(xiàn)了自動化。如果你有一項服務并且需要儲存數(shù)據(jù)，你可能每隔一段時間就需要對數(shù)據(jù)進行備份一次，然后需要每隔一段時間對數(shù)據(jù)進行修復。 這些數(shù)據(jù)備份和數(shù)據(jù)恢復工作都可以由內(nèi)部系統(tǒng)自動完成。備份是計劃好的，系統(tǒng)可以自動進行數(shù)據(jù)恢復的測試工作和完整性測試。 當系統(tǒng)檢測出某一盒磁帶出現(xiàn)故障時，它會自動進行處理。
o 作為人，你不需要了解這些東西。也許在未來的某個時候，你才會想起來去查看一下有多少磁帶出現(xiàn)過問題。 如果磁帶故障率發(fā)生變化，從每天100盒增加到每天300盒，系統(tǒng)才會發(fā)出警報。 但是在系統(tǒng)發(fā)出警報之前，系統(tǒng)是不會提示你每天有100盒磁帶出現(xiàn)問題是在正常范圍以內(nèi)的。
· 人工不應介入穩(wěn)態(tài)運行的系統(tǒng)。
o 包裝和運輸硬盤仍然需要人工來完成。 自動準備運輸標簽，獲得RMA編碼，核對發(fā)出的包裹，接收回執(zhí)，這都是自動進行的。只有當這個流程中斷時，才需要人為干預。
o 庫軟件維護也是如此。如果有一個固件需要升級，并不需要派一名員工去給每個系統(tǒng)升級。 下載固件升級，然后將它送到總控制庫即可。對固件升級進行測試，盡可能準確地驗證測試結(jié)果。 然后將它發(fā)出去。這套正常操作不需要人工干預。
· 自動處理設(shè)備宕機事故。
o 很多設(shè)備每分鐘會宕機兩次。如果在使用3萬臺設(shè)備執(zhí)行MapReduce作業(yè)時有一臺設(shè)備宕機，那就別告訴我了，只要自動處理好它然后繼續(xù)執(zhí)行作業(yè)就行了。 再找一臺設(shè)備，將工作負載移動過去，然后重啟設(shè)備。
o 如果設(shè)備之間存在關(guān)聯(lián)性，那就請在計劃中加一個等待指令。如果系統(tǒng)等待的時間太長，則可以向管理員發(fā)出警報。 你處理你自己的計劃工作。這是算法應該做的事，而不是人應該做的事。
· 在數(shù)據(jù)增長的同時，保持效率不斷提高。
o 提高利用率和效率。數(shù)據(jù)量增長100倍的時候，決不能出現(xiàn)對人員或設(shè)備的需求量也增長100倍的情況。
o 2011年的GMail宕機事故和修復情況。從中可以看出谷歌是如何丟掉數(shù)據(jù)然后又找回那些數(shù)據(jù)的。他在周日上午10:31收到一條警報信息，上面寫著：“Holly Crap呼叫xxx-xxxx”。如需了解更多關(guān)于那次宕機事故的信息，請點擊這里。
o Gmail服務的數(shù)據(jù)量已經(jīng)達到EB級了。那需要使用很多很多的磁帶。
o 100%恢復。數(shù)據(jù)可用性并不是100%。 丟失的數(shù)據(jù)在事故發(fā)生后的第一天或第二天并沒有全部恢復。 但是最終，所有的數(shù)據(jù)都被恢復了。
o 復制層發(fā)生了一系列故障和事故。是的，我們有三個相同的文件，但是它們都空了。 即使進行過設(shè)備測試、系統(tǒng)測試和裝配測試，故障也無法避免。
o 從磁帶恢復數(shù)據(jù)。這是一項繁重的工作。 數(shù)據(jù)恢復的時間與數(shù)據(jù)規(guī)模是成正比的。恢復1GB的數(shù)據(jù)也許只要1毫秒到幾秒的時間就行了。 但是要恢復20萬個收件箱（每個收件箱中都有幾GB的數(shù)據(jù)），那就要一些時間了。
o 叫醒了歐洲的兩名員工來處理此事，因為當時他們那里是白天。將人員分配在不同的地方，就是有這樣的好處。
o 數(shù)據(jù)被從每一盒磁帶上恢復過來，并經(jīng)過了驗證。這項工作沒有花太多的時間，只用了幾天就完成了。 員工們對此感到滿意。遇到類似事故的其他公司花了一個月的時間才意識到他們無法將數(shù)據(jù)恢復回來。 谷歌采取了一些措施來保證下次遇到類似事故時會更快地完成相關(guān)的處理工作。
o 讀一盒磁帶要花2個小時的時間。磁帶散布在很多地點。 沒有哪一個站點有足夠的計算能力去讀取所有與數(shù)據(jù)恢復有關(guān)的磁帶。
o 利用壓縮技術(shù)和檢驗數(shù)字技術(shù)，其實并不需要把20萬盒磁帶都讀一遍。
o 從那以后，數(shù)據(jù)恢復工作就一直在不斷改進。
· 為各種數(shù)據(jù)的恢復工作設(shè)定優(yōu)先等級。
o 你應該對各種數(shù)據(jù)的恢復工作設(shè)定優(yōu)先等級，比如先恢復你正在使用的收件箱的數(shù)據(jù)和已發(fā)送的電子郵件數(shù)據(jù)，然后再恢復歸檔數(shù)據(jù)。
o 一個月都沒有被碰過的帳戶可以放在后面恢復，優(yōu)先恢復相對比較活躍的用戶的帳戶的數(shù)據(jù)。
· 備份系統(tǒng)被視為一個巨大的全局有機組織。
o 例如，不要只在紐約備份GMail服務的數(shù)據(jù)，因為如果數(shù)據(jù)中心的規(guī)模擴大或縮小，備份數(shù)據(jù)的規(guī)模就應該相應地進行調(diào)整。
o 將備份當作一個巨大的全球性系統(tǒng)來對待。當備份發(fā)生的時候，它也許是在其他任何地點進行的。
o 利用磁帶來恢復數(shù)據(jù)必須在磁帶所在的地點進行。但是數(shù)據(jù)可以在紐約而備份卻在俄勒岡進行，因為俄勒岡的數(shù)據(jù)中心有足夠的容量。 地點隔離是自動處理的，谷歌沒有將數(shù)據(jù)的備份地點告知客戶。
o 容量是可以移動的。由于有一個全局容量并得到網(wǎng)絡(luò)的支持，因此磁帶在哪里并不重要。
· 你擁有的數(shù)據(jù)越多，數(shù)據(jù)備份工作就越重要。
o 東西越大就越重要，這是一條常規(guī)定律。谷歌以前只做搜索業(yè)務。 現(xiàn)在它有了GMail服務，因此它變得更大和更重要了。
· 建立一套優(yōu)秀的基礎(chǔ)設(shè)施
o 隨身攜帶一把瑞士軍刀真的很好。當MapReduce被開發(fā)出來的時候，他們可能從未想到過它會被用于備份。 但是如果不是已經(jīng)開發(fā)出MapReduce的話，那么人們也不會想到把它用于備份。
· 調(diào)整規(guī)模真的很重要，你不能只擁有它的一部分，比如軟件、基礎(chǔ)設(shè)施、硬件、流程等等。
o 你不能說，我有足夠多的員工，因此我打算使用更多的磁帶。如果你打算將員工人數(shù)增加一倍，先想想你公司外面的停車場是否能增加一倍的停車位吧。 公司的自助餐廳和休息室呢？ 每一樣都要增加一倍，最后你肯定會遇到一個過不去的瓶頸，然后不得不停下來。
· 在實際應用中證明它。
o 凡事都不要想當然。希望并不是一種策略。
o 如果你不去測試它，它就無法正常工作。要想驗證備份，就必須進行數(shù)據(jù)恢復工作。 除非你到最終都沒有證明任何東西。事實證明，這樣的做法會導致大量的事故出現(xiàn)。
· 災難恢復測試。
o 每過N個月都會出現(xiàn)一種災難。你應當在企業(yè)組織的每個層級模擬災難發(fā)生時的反應。
o 如果災難什么都不帶走，公司將如何生存呢？ 必須學會適應。
o 在基礎(chǔ)設(shè)施和物理安全設(shè)備中找出巨大的漏洞。
o 設(shè)想一下，如果有一個數(shù)據(jù)中心只有一條路通向外界，那么那條路上必然塞滿了運輸發(fā)動機燃料的卡車。如果那條路不在了，會怎么樣？ 最好再增加一條通道和另一條輸送柴油機燃料的供應管道。
o 制定供應鏈備用策略。
· 在不同的時間點和不同的地理位置及時對不同軟件的數(shù)據(jù)進行備份。
o 不要只是讓數(shù)據(jù)在不同的系統(tǒng)層級之間移動，而是應該將數(shù)據(jù)保存在系統(tǒng)的不同層級中。 這樣當你丟失某些數(shù)據(jù)時，你還可以從其他地方恢復它們。時間、地點和軟件，這都很重要。
o 以GMail宕機事故為例。如果復制軟件存在漏洞，怎么可能不出現(xiàn)數(shù)據(jù)丟失事故呢？ 這是某位聽眾提出的問題，他并不想要知道處理的細節(jié)。數(shù)據(jù)不斷被備份。 假設(shè)從晚上9點之后的數(shù)據(jù)我們都有，而數(shù)據(jù)錯誤是在晚上8點發(fā)生的，但是錯誤的數(shù)據(jù)還沒有被備份到磁帶上。 錯誤被停止了。軟件被恢復到之前某個正常運行的狀態(tài)。 在某一時刻，所有的數(shù)據(jù)都是完好的。那些數(shù)據(jù)都在磁帶上。 有些數(shù)據(jù)被復制了。 有些數(shù)據(jù)在前端，有些數(shù)據(jù)在日志里，這些數(shù)據(jù)源的某些數(shù)據(jù)是重復的，你是有可能重新所有的數(shù)據(jù)的。 在這些情況下，不要將數(shù)據(jù)從設(shè)備中提取出來，直到它被存入另一臺設(shè)備后過了N小時才能那么做。
· 刪除問題。
o 我想刪除這些數(shù)據(jù)。不要通過重寫磁帶的方式去刪除磁帶上的數(shù)據(jù)。 由于磁帶的規(guī)模太大，那樣做的成本就太高了。
o 有一種更加可行的做法是，利用密鑰來達到目的。它不會告訴我們谷歌在做什么。 也許鑰匙丟掉就等于把數(shù)據(jù)刪除了。
· 只有當員工們彼此信任且共同承擔責任時，一個規(guī)模龐大的組織才能高效運轉(zhuǎn)。
o 彼此信任。
o 確定組織界面和軟件界面都得到了明確的定義。在各個層級之間進行驗證測試。
· 制定白名單和黑名單。
o 確保數(shù)據(jù)被存放在一個受到保護的地方并且保證那些數(shù)據(jù)不會被存放到某個特定的地點。這有助于保證地點多樣性和地點獨立性。
o 這并不是設(shè)備固有的功能。必須添加到支持管理條件中。
o 將責任下方到盡可能低的層級。填寫正確的檔案，它就象魔術(shù)一樣發(fā)生了。
京公網(wǎng)安備 11010502049343號