包含下載下傳，資料安全，資料備份16條軍規

更多精彩請關注“資料和雲”公衆号

這可能是你需要的：

https://bethune.enmotech.com/

關注 Oracle 18c 新特性，Oracle 18.3 最新動态等

猛戳：http://enmotech.com/web/classify/31.html

近日，關于騰訊雲的一則事故在朋友圈刷屏

事件回放

騰訊雲披露的整個事件的基本情況如下：

8月6日 消息：近日，騰訊雲使用者“前沿數控”平台一塊作業系統雲盤，因受所在實體硬碟固件版本Bug導緻的靜默錯誤，檔案系統中繼資料損壞。

騰雲在聲明中稱，監控到異常後，第一時間向使用者告知故障狀态，并立即組織檔案系統專家并聯合廠商技術專家嘗試修資料，最終終仍有部分資料完整性校驗失敗。此外，随即對固件版本有bug的硬碟全部進行下線處理，確定相關隐患全部排除。

第一時間制定如下“賠償+補償”方案，包括包括全額返還 3569 元費用以及提供 132900 元現金或雲資源的額外補償。不過，"前沿數控"基于自身評估就此次故障對騰訊雲提出了高達 11，016，000 元的索賠要求，雙方未達成一緻。

而在使用者端，『前沿數控』的聲明則是：

...災難就發生在2018年7月20日，近千萬元級的平台資料全部丢失，包括經過長期推廣導流積累起來的精準注冊使用者以及内容資料，這瞬間将一家創業公司摧毀….

...花了兩年多心血打造的平台！當所有内容資料全部丢失，在這種情況下需要花多大代價才能恢複營運？還能營運得起來嗎？拿這13萬能用來幹什麼？那是我們公司的命脈！

...丢失的資料包括PC網頁、H5、小程式共用的核心資料。平台注冊的精準使用者資料全部丢失、數十萬條使用者文章全部丢失、行業品牌庫資料及所有錄入的資訊全都丢失。因為是高度垂直的行業，獲得流量是極其困難的事情...

而更有網友找出騰訊雲硬碟 99.9999999% 的可靠性承諾：

可是畢竟廣告好不好，還要看療效，9個9的可靠性，你也永遠無法論證你不是那 0.00000001%。

什麼是靜默錯誤

既然騰訊以9個9的代價換來的這次慘痛事故，公告中的“靜默錯誤”就非常值得關注了。那麼什麼是“靜默錯誤”呢？

靜默錯誤在英文中被稱為：Silent Data Corruption，我們知道硬碟最核心的使命是正确的存入資料、正确的讀出資料，在出錯時及時抛出異常告警。磁盤出現異常的情形可能包括硬體錯誤、固件 BUG 或者軟體 BUG、供電問題、媒體損壞等，正常的這些問題都能夠正常被捕獲抛出異常，而最可怕的事情是，資料處理都是正常的，直到你使用的時候才發現資料是錯誤的、損壞的。這就是靜默錯誤。

網上的一篇論文：Silent data corruption in SATA arrays: A solution - Josh Eddy August 2008 對靜默錯誤進行了解釋，我引用了一段文字進行說明，全文下載下傳請關注“資料和雲”公衆号“資料和雲”回複：122arch 獲得（我偷懶扔到之前的目錄中了）。

這篇文章提到：

有些類型的存儲錯誤在一些存儲系統中完全未報告和未檢測到。 它們會導緻向應用程式提供損壞的資料，而不會發出警告，記錄，錯誤消息或任何類型的通知。 雖然問題經常被識别為靜默讀取失敗，但根本原因可能是寫入失敗，是以我們将此類錯誤稱為“靜默資料損壞”。這些錯誤很難檢測和診斷，更糟糕的是 它們實際上在沒有擴充資料完整性檢測功能的系統中相當普遍。

在某些情況下，當寫入硬碟時，應該寫入一個位置的資料實際上最終寫入另一個位置。 因為某些故障，磁盤不會将此識别為錯誤，并将傳回成功代碼。 結果，RAID系統未檢測到“錯誤寫入”，因為它僅在硬碟發出錯誤信号時才采取措施。

是以，不僅發生了未檢測到的錯誤，而且還存在資料丢失。 在圖2中，資料塊C應該覆寫資料塊A，而是覆寫資料塊B.是以資料塊B丢失，資料塊A仍然包含錯誤的資料！

結果，資料被寫入錯誤的位置; 一個區域有舊的，錯誤的資料; 另一個區域丢失了資料，RAID系統和HDD都未檢測到此錯誤。 檢索B或C的通路将導緻傳回不正确的資料而不發出任何警告。

撕裂寫入

在其他情況下，隻有一些應該一起寫入的扇區最終會出現在磁盤上。 這稱為“撕裂寫入”，其導緻包含部分原始資料和部分新資料的資料塊。 一些新資料已丢失，一些讀取将傳回舊資料。 同樣，硬碟不知道此錯誤并傳回成功代碼，是以RAID無法檢測到它。通路檢索B将傳回部分不正确的資料，這是完全不可接受的。

上文提到的“撕裂寫入”，如果在 Oracle 資料庫中發生，那麼就是分裂塊，當然 Oracle 資料庫會自動檢測這種情況。

那麼“靜默損壞”發生的機率有多少呢？該文提供了一組資料：

...一項針對NetApp資料庫中150萬個硬碟驅動器的學術研究在32個月内發現，8.5％的SATA磁盤會産生靜默損壞。 某些磁盤陣列運作背景程序，以驗證資料和RAID奇偶校驗是否比對，并且可以捕獲這些類型的錯誤。 然而，該研究還發現，背景驗證過程中錯過了13％的錯誤。

那些未被發現的錯誤，就會成為企業的災難。雖然我們不知道騰訊雲所稱的“靜默錯誤”是否與此相關，但是靜默錯誤的确值得大家去了解。

即便沒有任何錯誤，資料也需要定期進行讀取，以確定資料無誤，在幾年前，我遇到過一起案例，Oracle 資料庫莫名的發生了一定批量的資料損壞，存儲上沒有任何錯誤，但是資料庫端大量的分裂塊，存儲沒有檢測到錯誤，并且複制到災備站點，最後導緻了資料丢失。

 對錯與利弊

我們姑且不要讨論誰對誰錯，我們要知道：隻要是硬體就有損壞的一天，隻要是運維就有誤操作的可能。而且，有一句名言說的好『小孩子才分對錯,成年人隻看利弊』。雲給了我們便利之處，也就一定會有風險相随。

也許很多人已經忘記了廣西移動在 2017年9月8号發生的大事故。僅僅因為一個代碼 0 和 1 的輸入，就引發了影響 80萬 移動使用者的大故障：

當晚淩晨，該工程師将代碼輸錯（1輸成0），導緻格式化，進而讓80萬移動使用者的資料遭到清空。事發後，中國移動10086收到了将近2萬多條電話投訴，移動和華為立即啟動緊急排查處理，整個事故在第二天早上10點才得以控制。

而近年，在雲服務商處發生的重大事故可以說是『層出不窮』，國内國外盡皆如此，列舉幾個 2017 年的事故：

2017年1月20日，大約一定是受到川普上任的影響，突如其來的伺服器故障影響了一大批爐石玩家，恢複時間長，由于意外斷電，導緻資料庫損壞，不得不通過遊戲回檔恢複資料庫的使用。（關于爐石傳說的Oracle資料庫故障不要以為你也可以幸免）

2月1日，除夕剛剛過完，荷蘭的一個DBA在資料庫複制過程中意外地删除了一個錯誤的伺服器上的目錄，删除了一個包含300GB的實時生産資料的檔案夾。300G的資料庫被删成4.5G，由于沒有有效的備份，嘗試了所有5個恢複工具都沒有完成恢複。在丢失資料并恢複失敗後，伺服器徹底崩潰。（五重備份無一有效，還有哪些 rm -rf 和GitLab類似的憂傷？）

2月11日，網絡剪報服務商 - Instapaper 遭受了超過31小時的服務中斷，聲明需要一個星期的資料庫恢複時間，然而經過10天的恢複，也僅僅恢複了6個星期的資料。（雲服務真的靠譜嗎？ AWS 使用者中斷31小時僅恢複6周資料）

2017-04-05，位于紐約的雲服務商 Digital Ocean 遭遇了一次長達4小時56分鐘的停機事故，事故的原因是主資料庫被删除了（primary database had been deleted），由于配置錯誤，本應指向測試環境的任務被指向了生産環境，測試任務包含的環境初始化過程删除了主生産資料庫。（不以規矩不成方圓：Digital Ocean也删除了他們的資料庫）

2017年6月 位于荷蘭海牙的一家雲主機商 verelox.com， 一名前任管理者删光了該公司所有客戶的資料，并且擦除了大多數伺服器上面的内容，客戶資料恢複希望渺茫。（參考：2017，那些我們一起删庫跑路的日子）

而近在今年4月，香港一家雲服務上也聲明，因為管理者的 rm -rf /* 操作，導緻所有的資料丢失：

正所謂，硬體一壞，誰也沒招，線路再穩，藍翔報帳，功夫再高，也怕菜刀。

 資料備份守則

對于運維來說，最重要的是提高自身的免疫力，獲得高抗風險能力，進而在災難中幸存下來。事關企業資料安危的情況，無論如何都不能疏忽大意。

是以，無論走的多遠，也不要忘了最基本也正是最重要的備份，有效的備份才能讓企業高枕無憂。怎樣保證備份的有效性？那就要做到不僅僅備份，而且還要定期檢測備份。

還記得Google曾經轟動一時的流水線删庫事件，這可是團隊作案喲，這麼團結真的好嗎？（時移世易：遵從既往經驗緻 1.5PB 資料删除，Google SRE是如何應對的？）

一個 Google Music 使用者彙報某些之前播放正常的歌曲現在無法播放了。Google Music 的使用者支援團隊通知了工程師團隊，這個問題被歸類為流媒體播放問題進行調查。3 月 7 日，負責調查此事的工程師發現無法播放的歌曲的中繼資料中缺少了一個針對具體音頻資料檔案的指針，于是他就修複了這個歌曲的問題。

但是，Google 工程師經常喜歡深究問題，也引以為豪，于是他就繼續在系統中查找可能存在的問題，當發現資料完整性損壞的真正原因時，他卻差點吓出心髒病:這段資料是被某個保護隐私目的的資料删除流水線所删掉的。Google Music 的這個子系統的設計目标之一就是在盡可能短的時間内删除海量音頻資料。

該流水線任務大概誤删除了 60 萬條音頻檔案，大概影響了 2.1 萬使用者.

沒有什麼是絕對可靠的，是以要選擇相信自己。

我在多年以前總結的 DBA 四大守則，第一條就是『備份重于一切』。

針對Oracle資料庫，一套 ADG 環境是最簡單的資料保障，備庫加上備份，就能夠防範硬體故障這個層面的災難性資料損失，MySQL 通過主備同樣可以實作類似的架構。當然您的資料有多重要，應該采取的技術措施就應該有多完善，任何疏忽肯定都是在冒險。

然而對于企業來說，您必須要牢記的是：如果您不能承擔資料全部丢失的損失，就要做好自主的可靠資料備份。依賴自己最可靠，依賴他人有風險。

針對種種安全風險，我曾經總結了提升資料庫安全的"16條軍規"供大家參考，很多朋友也向我們詢問，如何做才能夠徹底防範這類風險，我想你可以從以下16條建議中找到答案：

備份重于一切

我曾經在總結的DBA四大守則的第一條就指出，『備份重于一切』，有了有效的備份，即使遭遇災難，也可以從容應對，對于重要的生産環境，适當建立備庫進行資料保護，查詢分擔，也會減少生産庫的風險；

唯一會讓DBA們從夢中驚醒的就是:沒有備份! 是以對于資料庫運維來說，第一重要的是做好備份!有備方能無患!

嚴格管控權限

過度授權即是為資料庫埋下安全隐患，在進行使用者授權時一定要遵循最小權限授予原則，避免因為過度授權而帶來的安全風險。本次安全風險，如果使用者隻具備最低權限，如不具備DDL權限，那麼也不會遭到風險；

明确使用者職責

應當明确不同的資料庫使用者能夠用于的工作範圍，應當使用普通使用者身份的，就絕對不應該使用DBA的使用者身份，隻有職權相稱，才能夠避免錯誤，降低風險。 即便是擁有管理者職責的使用者，也應當遵循以不同身份執行不同任務的習慣，比如SYS和SYSTEM使用者的使用就應當進行區分和界定；

密碼政策強化

毫無疑問，資料庫使用者應當使用強化的密碼規則，確定弱密碼帶來的安全風險，很多資料洩露問題來自弱密碼攻擊和提權；

限制登入工具

明确限制不同工具的使用場景，明确規定工具的準确來源，或者通過堡壘機等來限制資料庫通路。對于工具也可以做出明确規則和限制，如限制僅能通過SQL Developer通路生産，PL/SQL Developer工具僅能通路測試環境，以減少安全風險甚至誤操作風險；

禁止遠端DDL

可以限制DDL操作僅能在資料庫伺服器本地進行，禁止遠端連接配接執行DDL操作，這一手段在很多公司被嚴格執行，如果具備這一規則，此次的事故可以被直接屏蔽掉；

使用綁定變量

在開發過程中，嚴格使用綁定變量，綁定變量可以防範SQL注入攻擊，減少資料庫安全風險；這次安全事故，很多使用者開始猜測是SQL注入，走了很多分析上的彎路；

監控監聽日志

監聽日志記錄了資料庫通路的來源、程式等資訊，包括惡意掃描，密碼嘗試等，一定要重視監聽日志的作用，并對其進行分析和監控，以清楚的彙制資料庫通路圖譜；雲和恩墨一直幫助使用者通過監聽日志分析來揭示風險，白求恩平台（ https://bethune.enmotech.com ）為使用者免費提供這一分析緯度的預警；

資料網絡隔離

資料庫的網絡環境應該一直隐藏在最後端，避免将資料庫置于直接的通路連接配接之下，由此可以減少資料庫的通路風險；

測試和生産隔離

互通就意味着同時可以通路，也就可能帶來很多意想不到的安全風險，企業應當将測試環境和生産環境部署于不可互通，或者不可同時通路的網絡環境中，避免因為錯誤連接配接而發生的資料庫災難。 分離部署一方面可以降低誤操作的可能性，也可以屏蔽一些無關的通路可能，進而從網絡鍊路上保證資料安全；

密碼差異設定

有些測試環境或者非産品環境是利用産品環境恢複得到的，DBA在建立了測試環境後，就沒有修改資料庫使用者的登入密碼;經常性的，DBA也習慣在所有環境中設定通用的密碼;這些習慣為系統帶來了很多風險和不确定性。 我們建議使用者在不同環境中采用不同的密碼設定，這是因為一方面産品環境和測試環境面對的通路使用者不同，密碼設定相同則意味着産品環境的安全性完全得不到保障;另一方面，DBA登入到不同的資料庫需要使用不同的密碼，這進一步減低了DBA在錯誤的環境下執行指令的可能性。

重要資料加密

很多重要的資料，需要加密存儲，最典型的就是使用者和密碼資訊，大量的洩密事件本質上是因為缺乏最基本的加密防範，對重要資料實施一定的安全防護加密，是應當予以适時考慮的安全方面之一；

适時的軟體更新

這裡的軟體指資料庫軟體，尤其是當Oracle已經釋出了安全更新檔，已知的安全漏洞被黑客利用，則更可能對資料庫産生緻命的傷害；

防範内部風險

不可否認，絕大部分安全問題都來自于企業内部，來自最緊密、最輕易的接觸和通路，企業的人員變動，崗位變更，都可能導緻資料安全問題的出現，單存依靠對管理者的信任不足以保障資料安全，必須通過規章、制度與規 範的限制才能夠規避安全風險。

很多企業為了便利而舍棄規範、規章或者安全限制是得不償失的做法。安全防範應當從内部做起，從限制限制自我做起，當最緊密相關的通路都遵從守則，那麼系統的安全性就能夠獲得大幅度的提升。

樹立安全意識

安全問題最大的敵人是僥幸，很多企業認為安全問題機率極低，不會落到自己的環境中，是以對于安全不做必要的投入，造成了安全疏忽。是以安全問題最大的敵人是我們自己，安全需要一點一滴的加強，逐漸完善，雲和恩墨一直幫助核心客戶進行全面的安全評估，制定安全方案，守護資料安全。

開始安全審計

以Oracle資料庫為例，資料庫已經提供了很多安全防範的手段和方法，我們建議使用者适當展開安全防範措施，開啟部分任務審計，定期分析資料庫風險，由此逐漸完善資料庫安全。

關注安全，更重要的是意識，陽光之下，并無新事，努力請從今日始！

這可能是你需要的：

https://bethune.enmotech.com/