從數據恢復角度分析騰訊雲靜默損壞
根據這個表述，故障應出現在硬盤固件故障導致的文件系統元數據損壞。這其中，涉及具備因果關系的三個知識點：
硬盤固件故障—>文件系統元數據損壞—>文件損壞。
在此大致畫一下騰訊雲可能用到的存儲架構方案。
帶*號的是不一定存在的存儲鏈。事實上，這個邏輯肯定不準確，比如有些環節精減或不需要，有些環節有更詳細的設計等。但是不是和真實場景一致不重要，重要的是，問題如果出現，總會出現在我列出的項或我沒列出的項中(廢話)，這些項是相互關聯的。
我們再重復一下現象：硬盤固件故障(層1故障)導致的文件系統元數據損壞，從而導致部分文件校驗出錯，導致文件損壞。針對現象，努力從上述10個環節匹配，每一層會有可能出錯，導致上述故障嗎：
第1層：存儲介質
以硬盤為例，每個構成數據的最小單位扇區都會有嚴格的校驗，包括扇區頭部的CRC校驗以及地址標識校驗。理論上，如果層1的數據出現磁力失真(或閃存狀態丟失)等比特出錯，其頭部校驗不匹配時，介質控制器就會向上層反饋錯誤(一般表現為壞扇區)，上層會啟動修正模式進行修正。
當然也有例外，比如硬盤內部程序出錯，根本不按上述原則執行，忽略校驗值的情況下，任何對數據的篡改都是可以的。可以表現為騰訊所說的靜默損壞（即層1在合理的邏輯裏偷梁換柱)。這種情況，基本大帽子就能扣在硬盤固件BUG這上面了，但硬盤固件這種BUG是致命的，等同於我們存進銀行的錢不知什麽原因變多或變少，沒有硬盤廠商站出來承認，也沒有緊急發布BUG修復固件，完全歸因於硬盤固件，可能偏激了些(也可能事件背後有固件BUG的原因，那也應該是添油加醋型的)。
第2層：RAID
RAID自身有冗余算法，可實現在部分介質（硬盤）損壞後，由其他成員及算法控制來接管損壞硬盤的數據服務，保證上層業務不中斷，不出故障。但RAID也並非完全可靠。
一種錯誤是軟RAID中的寫漏洞(write hole)，如果是軟RAID，這無法避免，可能導致騰訊本次事故。但軟RAID是玩具產品，自然騰訊是不會用這種方案的。
還有可能的錯誤是buffer?dirty，當緩沖數據掉電清空，或有意無意損壞後，會導致數據出現本例的表現錯誤。但這個原因可以很容易推到控制器BUG上面，騰訊沒提及這個原因，或者是他們沒找到病根，或者的確和這個無關。
還有最可能的錯誤是RAID中超過冗余數量的磁盤損壞。比如RAID5只支持一塊盤損壞，但現實中出現了：
情形2：1塊損壞後未及時重建，第2塊又損壞
情形2出現的可能性非常大，幾乎IT類公司沒有不濕鞋的，只是數據或不重要，或未千萬公眾效應。本次騰訊事故，情形2導致的數據災難，不是沒有可能。想象一下，以RAID5為例，若底層RAID有硬盤壞，管理人員沒及時跟進重建，希捷負載加重後，其他硬盤壞，是非常正常的事情。更有一種情況，與硬盤固件有關，就是硬盤已經有壞道了，但並未碰觸到壞道區，這時表現一切完好，一旦重建，就會導致RAID崩潰。
一般而言，工程師的修復方法就是強制上線，讓帶病的硬盤強行工作，也可能不懂的工程師隨便上線了舊掉線的硬盤，這時，就會表現為大多數數據可訪問，但部分數據（尤其較新）出現損壞，與騰訊公開的表現相似。
第3層：虛擬卷層
虛擬卷往往用在大的雲存儲中心，簡單地舉例來說，如果由1000個硬盤構成的一個存儲系統，再按8硬盤一組的方式進行存儲劃分，會有很多問題(高故障、空間利用不集中等)。為此，很多廠商開始提及虛擬化存儲，方法各有不同，但基本就是存儲池化---意思是所有可用的空間在確保案例的前提下，匯總到一個統一管理的“池”中，再根據需求靈活分配虛擬磁盤。
一種方法是把所有硬盤放到池子裏，再切塊組RAID，再組個存儲池，再劃分虛擬卷。華為把這個技術稱為RAID2.0，其實HP EVA、3PAR也都按這個技術在實現(網絡上的主流資料描述HP EVA的算法均有誤)，DELL康貝(Compellent)都是這樣實現。這種思路硬盤如果足夠多，在使用前期安全性很好（有足夠多的混在隊伍中的替補，可以快速替換故障數據塊），但後期隨著損壞硬盤數量的增加(尤其越是自動替換，管理人員就越松懈)，故障率就會增加。
舉個HP-EVA的例子，一組存儲144個硬盤，在崩潰臨界點，先後有近40個硬盤報故障。故障的根源其實來源於硬盤預警失效、控制器又完全呆傻的BUG。40個故障硬盤遠遠超過可以激活系統的故障數量，就導致所有部署在本存儲上的數據全部下線。一般HP官方的最高解決辦法(美國的一線)，就是用指令強行激活存儲，讓存儲自己計算缺失數據，當數據的確落到壞道處無法校驗生成時，就會用舊狀態數據(EVA快速重建時會可能保留某些數據塊的舊狀態)或全0代替。這樣，就會導致上層文件系統故障。文件系統故障就是表現為元文件故障，否則元文件沒壞，文件系統就不會壞，頂多表現為文件內容不正確。
騰訊本次的事故也有這個可能。
另一種方法是把所有硬盤按xD+yP的方式構建RAID(如8個硬盤的數據，配一個硬盤的校驗)，再把所有的RAID放到池裏，再從池中劃分虛擬磁盤。IBM DS8000、HP X20000、DELL EqualLogic都用這個方案。這是非常垃圾的方案，IBM和HP的上述兩類存儲都是上千萬一套的產品，但故障風險極大，我們的國企，政府常用，也常出問題，只是沒人知道。故障主要來源於不斷放大的RAID風險，每一組RAID假設有1/10000的概率損壞(如第2層中的情形2)，如果1000個硬盤，有100組，損壞概率就放大了100倍，想想也可怕。但騰訊本次事故不太可能用IBM、HP、EMC的存儲，因為太貴了，又不是存自己的核心數據。可能有小廠商或騰訊自己用軟件定義的方式搭建本類存儲，損壞的可能也就如同第2層中的情形2。
第4層：虛擬卷快照
快照是對某個數據集某個時間段的差異數據組合。快照集疊加到其父集上，就可以表現為最新的數據副本。集中在快照上的故障往往因人為發生，比如以為某個快照副本已經失效，刪除後發現刪錯了；比如在回到某個快照狀態時選錯了，再也退不回去等等。
如果照著騰訊本次的事故，至少有一種可能會導致故障現象的發生：管理人員因故(遷移、維護等原因)對數據做了快照，在清理臨時數據時不小心刪除了快照副本，緊急搶救後，快照數據救回來有部分損壞，快照合並後表現為部分數據損壞。當然，這個可能性不大，騰訊本次事故中沒有選擇數據恢復專業公司介入(只要有選擇數據恢復方案，北亞不會不知道)，應該不會有這種實施可能。
第5層：大數據或雲存儲層
出問題的騰訊雲是基於虛擬化技術構建的，涉及虛擬化，就一定會設計資源的集中分配。涉及數據部分，單一或獨立存儲很難響應IO的不確定性峰谷請求，所以，騰訊應該會設計Hadoop之類的平臺來提供數據資源分配。
在大數據平臺的設計邏輯裏，數據IO資源會以可能平均地分配在所有節點中。而管理他們的元數據或集中或分布式。邏輯上，用戶數據與元數據是獨立的。
但現在的大數據平臺往往是基於傳統單機文件系統為載體進行架構。單機文件系統的操作手段、命令並未廢止。所以，在一些情況下，大數據平臺出故障，可能會導致騰訊類似的數據災難。
僅僅是舉幾個想象的例子。
如果維護人員不小心刪除大數據平臺下一層文件系統上的某些數據塊，大數據平臺的冗余也無法還原某個數據塊的話，就會表現某個用戶的虛擬機數據缺失。
如果維護人員沒及時維護節點，某些節點損壞，超過了冗余級別，也會導致某個用戶的虛擬機數據缺失（也有可能用VMware vSAN之類的技術，同樣這種可能也存在）。
騰訊的事故是否如此，不得而知。
第6層：虛擬化文件系統
VMware?vsphere、Xen、KVM或Hyper-V是專門的虛擬化系統平臺。這些虛擬化平臺，為了實現塊級別的同時訪問，且適應虛擬機的大塊分配原則，有時要設計自己的文件系統，最為典型的是VMware的VMFS。
以VMFS為例，對VMFS引發本次事故表現的可能舉舉例子，如下：
1、VMFS是典型的共享塊設備文件系統，是基於每臺VMWARE服務器的約定，如果接入存儲網絡的是普通單機，他可不管是不是共享，有時就會獨占存儲設備，導致VMFS的破壞。強行修復後，就會出現某臺虛擬機數據損壞的情況。
2、VMFS管理時不小心刪除數據，或擴容、縮容，也會導致VMFS文件系統損壞，修復後，可能出現某臺虛擬機數據損壞的情況。
第7~8層：虛擬磁盤文件與快照
虛擬機的數據載體是虛擬磁盤，往往表現為宿主系統上的一個文件或一個獨立區域。以文件形式表現的居多，如RAW、VMDK、VHD、VHDX、QCOW2等格式。
這些虛擬磁盤和普通文件表現相同，就會面臨和普通文件一樣的損壞可能。比如上層誤刪除文件、上層格式化、文件截斷、文件遷移時中斷等。這些文件一旦破壞，即使恢復回來，也可能不是100%，就會與騰訊本次數據災難的表現相同。
磁盤文件快照與第四層的卷快照原理相似，Hyper-V對其稱為差異磁盤，表述直接明了。快照文件丟失或損壞後，也可能與騰訊本次數據災難表現相同。
第9層：虛擬機文件系統
分配給用戶的虛擬機，其硬盤就是前文提到的虛擬磁盤文件，但進入虛擬機後，就等同於物理硬盤。這些硬盤也被正常操作方法分區、格式化、安裝系統、安裝應用等。不論Windows的NTFS、Linux的Ext4等，文件系統總會可能有突發性的災難。但本次事幫顯然不屬於此，僅聊聊可能的數據風險。
一是來自誤操作。如格式化、刪除數據、同名文件覆蓋等。
二是來自系統bug。但bug並非是特別明顯的，有時是需要多方環境因素催化。舉個例子，在NTFS上打開卷壓縮，存入一個上百GB的文件，文件系統8成會崩潰，連現有文件都可能找不到(在早些年，我做了很多這處條件下的試驗，最終確定的確是系統bug，最近未做實驗，或許Microsoft已修正)。另一個例子，非常常見，在WINDOWS上運行ORACLE數據庫，數據庫文件的增長粒子設置過小(比如1M之類)，當數據大小到上百G時，不出5年，幾乎肯定會崩潰(數據文件大小截為0，或內容交串出錯)。
第10層：文件
這一層沒什麽好說的，往往是來自於上述幾層的故障，導致文件損壞。除此之外，就謹防勒索病毒吧。
建議
數據災難大方向有2個：人為災難和不可抗力災難。能給出的建議大概如下：
1、備份。
備份的重要性毫無疑問，但要講方法，為避免硬件故障，就不能備份在同一個或同一類硬件載體上；為避免自然災害，就要異地備份；為避免備份集過多帶來的管理問題（找數據都費勁之類的），應制定良好的備份計劃；為避免同類介質受環境的影響，就應該考慮不同介質的方案，如光存儲與磁存儲各自備份；為避免有意或無意破壞，備份集就應該設不同的存取權限，不能一把鑰匙開所有門……
2、規範管理和實施。
很多企業級數據災難往往來自於人為，因為任何一個系統，在涉及維護的時候，都必須工作在無保護狀態，任何一個不小心都可能導致無法回溯的後果。制定嚴格的維護實施方案、備份計劃、預警機制是非常重要的保障。
3、數據取舍。
太老的數據就刪了吧，再對數據精簡整理，再做詳細的管理計劃。要知道，娶妻越多，頭頂發綠的機會就越大。
從數據恢復角度分析騰訊雲靜默損壞