資料庫資料恢複環境：
華為雲ECS，linux作業系統；
mysql資料庫，執行個體内資料表預設存儲引擎為innodb。
北亞資料恢複——mysql資料恢複
資料庫故障：
在執行資料庫版本更新測試時，使用者誤将本應在測試庫測試的sql腳本執行在生産庫中，導緻部分表被truncate，部分表内少量資料被delete。
資料庫恢複過程：
1、由于該ECS内有其他業務在正常運作中，為避免被truncate表的底層資料不被破壞，首先鏡像備份mysql資料庫data目錄所在分區。
北亞資料恢複——mysql資料恢複
2、由于需要恢複的被truncate表不存在大字段類型值和myisam引擎表，資料恢複工程師使用工具掃描資料段并下載下傳恢複資料所必需的mysql資料庫段碎片。由于innodb引擎表的資料恢複必須依賴表結構資訊，mysql的表結構資訊存儲于對應表名的.frm檔案内。經過檢測發現在本案例中的.frm檔案完好，可直接使用。下載下傳需要的表對應的.frm檔案。
北亞資料恢複——mysql資料恢複
3、讀取資料段内系統表資訊，擷取需要恢複的表在系統表内的注冊資訊。
4、在下載下傳完成的資料段檔案内提取對應于各表的資料頁，解析對應表的.frm檔案擷取到該表的表結構資訊。通過表結構資訊擷取到底層資料配置設定規則，按照規則拆分資料段内二進制資料并對不同類型進行字元展示轉換（各類整型、浮點型、時間型等），完成資料段到sql語句的轉換。
5、恢複被delete資料的表，過程和恢複truncate表的類似，不同點在于解析資料時需要提取被标注為“delete”的記錄。
6、根據解析出的表結構資訊在環境中的mysql執行個體内建立表，并将恢複出的資料導入。
北亞資料恢複——mysql資料恢複
北亞資料恢複——mysql資料恢複
7、由于直接從底層抓取出的記錄可能存在主鍵不唯一（引擎在存儲時産生的臨時記錄）和記錄重複（緩沖段）以及亂碼（掃描資料段時出現特征值比對成功但不屬于該表的資料段）等情況，提取出的記錄可能存在異常，需要北亞企安資料恢複工程師手動處理。
8、開啟遠端桌面，由使用者驗證資料的準确性和完整度。經過反複驗證，truncate表和delete記錄的表都完整恢複。