前陣子爆出教育史上最嚴重的重大資料遺失事件，因為人為VM設定失誤，導致2萬多件學習歷程的數位檔案因為移機而消失不見！
到底是什麼樣的設定，會讓資料全部丟失？以下就來深入分析。
VMware的磁碟模式千萬別設錯，以免資料都不見
OSSLab日前接受IThome專訪，提到VMware ESXi的磁碟模式有分成幾種模式，並分析導致這次資料消失的主要元兇，就是套用了錯誤的VM設定樣板 (誤選到「測試環境設定」的樣板)，導致移機時因為要將VM關機，而關機後硬碟資料就會恢復到先前剛設定VM時的狀態，使得VM在先前開機這一段期間，學生所上傳的資料都等於儲存在「暫存碟」上，而該期間又沒設定好VM備份或是資料庫備份，這一連串的失誤，導致該VM一關機，就恢復到先前的建置環境，讓學生們先前上傳的資料全部都不見。
深入分析，該工程師可能設定到「獨立 – 非持續性 (Independent – Nonpersistent)」這種模式，其運作方式有點像是以前那種「還原卡」的設定，類似網咖電腦的環境，只要一重新開機，先前儲存的資料都會被丟棄。要是開機過程中沒做任何備份作業，就會導致資料都不見。而在災害發生後，也沒做到事後的補救措施，導致連最後資料救回的機率大幅降低，爆出這次的嚴重資料遺失事故。
VMware ESXi 磁碟模式解說
VMWare ESXi在設定磁碟的頁面中，有分成以下幾種模式，分別說明如下：
▼ 磁碟模式選項說明 (取自 VMware官網)，藍字標示區即為這次案例所設定的模式
● 磁碟模式: 相依 (Dependent)
正常情況下，應該設定這種模式 (或「獨立 – 持續性」模式也是OK的)。
▼ 剛建好的狀態，檔案內容單純
▼ 準備建立快照，檔案內容同上
▼ 建好快照後，檔案內容會增加至 SEsparse.vmdk檔
▼ 開機進入Windows後，變動資料會寫入SEsparse檔 (仔細看檔案長度)
▼ 下載一個3GB檔案，SEsparse檔案長度增加 (白色部份)
▼ 虛擬機關機後，SEsparse檔案長度維持不變
▼ 下次開機時，檔案仍在，SEsparse檔案仍在 ← 這是一般正常情況下的磁碟模式，資料關機後都還會存在
● 磁碟模式: 獨立 – 非持續性 (Independent – Nonpersistent)
這次的事件，有可能就是選到這種類似還原卡模式，一旦VM關機，資料就不見! (VMware官方也建議避免使用此模式)
▼ 剛建好的狀態，檔案內容單純
▼ 準備建立快照，檔案內容同上
▼ 建好快照後，只會有一個snapshot vmsn檔案
▼ 開機進入Windows後，變動資料有寫到SEsparse.REDO暫存 (仔細看檔案長度)
▼ 下載一個3GB檔案，SEsparse.REDO檔案長度增加 (白色部份)
▼ 虛擬機關機後，那個SEsparse.REDO檔案不見了!
▼ 下次開機時，後來下載的3GB檔案當然看不到了! ← 這就是設定錯誤之後，導致關機後資料就不見
災害發生時的正確步驟
若不幸發生VM資料遺失，且沒備份。那麼第一個步驟就是要「避免系統額外寫入」，並將所有的「LUN儲存空間(實體硬碟/RAID硬碟/網路硬碟等)都卸載(unmount)或斷線(disconnect)」並關機，這麼做的目的就是要避免額外的寫入動作把原本有機會救回來的資料覆寫(overwrite)掉!
接下來的第二步，就是將那些LUN儲存空間實體(硬碟或儲存設備)交給專業的資料救援公司來處理，資料救援公司會透過分析硬碟陣列或儲存裝置的組成架構、VM設定模式，以及其分割區設定，來嘗試將資料還原。當然這個步驟是冗長且需要非常了解Infra的專業工程師才能辦得到，因此為爭取時效，建議企業還是要以緊急專案來特別處理這類的案子，以免影響企業營運。
災害發生後若想嘗試自救，記得先全機鏡像
如前述，災害發生時的第一步驟，就是要避免更多的寫入動作。然而一般MIS所採取的資料恢復處置，幾乎都有寫入的動作，例如下 fsck或是 chkdsk 指令，雖說可以嘗試修復檔案錯亂，但這些操作都有機會寫入資料，而且每下一次指令，就又有log寫入動作。有可能是一般IT人員不知道其內部原理，難以判斷這些補救動作所造成的風險。更甚者是有些動作可能造成不可逆的狀況，增加資料救援的難度。
若想要嘗試自救並非不行，而是記得要先全機鏡像，以免造成資料二次毀損。然而，如此巨量的LUN備份其實有一定程度的門檻，原因如下：
- 第1: IT人員需有正確且實際操作經驗，以免操作失誤造成資料二次傷害。
- 第2: 需要夠大的備援儲存空間，因為這是整台或整座儲存伺服器等級的備份，因此平時公司需要有足夠的儲存設備來應急，若沒有的話，想要緊急採購，廠商也不一定會馬上交機。
- 第3: 鏡像/備份是很花時間的，且要怎麼鏡像，選擇鏡像哪些LUN才最有效率。
綜合上述幾點可知，不是每家企業都能自己來。要是考量時效與資源的需求下，就選擇第一時間送到資料救援公司來處理吧! 因為上述的問題都不會有，這樣會比較省事一些。
▼ 以WinHex來整機磁碟進行 dd 鏡像
VMware資料的救援方式簡述
資料救援採用的步驟，就是類似逆向工程的手法。簡單來說，其實要對檔案系統底層非常了解。以VMware VMFS檔案系統來說，其採用傳統inode塊位檔案系統，其有個索引表會記錄所有檔案位置，且位址分配方面也相當嚴謹，當有檔案被刪除時，其刪除的並非真正的實體資料，而是其佔用的檔案空間。作業系統會在索引表做註記，將這段檔案空間給釋放出來，因此原來的資料還在硬碟裡，只是一般情況下是看不到的。
至於開始進行VMFS的資料救援時，就需要逆向檔案系統工程的技巧，此時會借助開源程式或腳本，來進行程式碼解讀(code review)，也會根據個案需求來寫出自己的腳本程式，這樣才有辦法找出被刪的實體資料。由於市面上現成的資料救援軟體支援度還不夠新，例如無法支援到VMFS 6、無法支援快照等。此時就得走工具腳本的方式來處理。
▼ 此圖例為RAID且為Linux檔案格式下，將VMware虛擬機內的Windows資料救援之拓樸圖。客戶資料毀損到的層級越低層，救援難度就更加困難
若想省事，建議第一時間找專業的救援公司處理
綜合上述，資料搶救的第一步，首先就是要確保系統沒有額外寫入，將VM主機連接到的所有LUN儲存空間都先離線並關機。接下來，就是將原始的LUN儲存裝置交給專業資料救援公司，這樣資料救回的成功機率就會比較高。要是想嘗試自救，非得執行寫入動作前，記得確實備份好LUN，或對硬體建立好快照，才開始操作，以避免資料遭到覆寫而導致難以救回的狀況。
想找專業資料救援公司來幫忙的話，就建議找資料救援技術第一品牌的OSSLab吧! 我們OSSLab擁有最全台geek的資料救援工程師，累積各式各樣的IT infra與儲存經驗，了解RAID運作原理且具有自行coding的能力，除分析出問題的根本原因外，還會提出可行的解決方法與加速救援效率。我們為多家企業的巨量儲存救援需求，常備各式儲存伺服器，也親訪過公家機關現場，在地進行專業處理。會為您全心全力救回寶貴的資料。
