一、Ceph故障表現
故障情況：客戶設備為Ceph分布式存儲系統，采用RBD（RADOS Block Device）作為塊存儲服務。Ceph集群由多個OSD（Object Storage Daemon）節點組成，數據通過CRUSH算法分布存儲在多個物理節點上。在系統運行過程中，由于誤操作執行了初始化重置命令，導致Ceph集群的元數據信息被重置，存儲池（Pool）配置丟失，RBD卷的映射關系被破壞，整個存儲系統中的數據無法正常訪問。目標需要恢復的RBD卷中存儲了一臺虛擬機的完整磁盤鏡像，該虛擬機內部運行TiDB分布式數據庫系統，包含重要的業務數據。
恢復概率預判：
由于是初始化重置操作導致的元數據丟失，底層物理數據塊可能仍然完整保留在OSD節點上。Ceph采用對象存儲架構，數據以對象形式存儲在OSD中，每個對象包含數據本身和元數據信息。如果底層物理存儲介質未發生物理損壞，通過底層掃描和元數據重建，理論上可以恢復RBD卷數據。恢復難度取決于Ceph版本、存儲池配置參數、對象大小設置等因素。由于Ceph分布式存儲的復雜性，需要深入分析CRUSH映射規則、PG（Placement Group）分布、對象存儲結構等，恢復工作可能會耗費較長時間。
虛擬機恢復后，還需要對TiDB數據庫進行解析，提取庫表記錄數據，整個恢復過程需要分階段進行。

二、Ceph存儲系統架構概述
Ceph是一個開源的分布式存儲系統，采用去中心化架構設計。核心組件包括：
1、MON（Monitor）：負責維護集群狀態映射，包括OSD Map、PG Map、CRUSH Map等元數據信息。
2、OSD（Object Storage Daemon）：負責實際的數據存儲，每個OSD管理本地存儲設備，將數據以對象形式存儲。
3、MDS（Metadata Server）：用于CephFS文件系統，RBD場景下不涉及。
4、RBD（RADOS Block Device）：提供塊設備接口，將RADOS對象組合成連續的塊設備。

Ceph數據存儲機制：
- 數據寫入時，通過CRUSH算法計算數據應該存儲在哪些OSD上，實現數據的均勻分布。
- 每個RBD鏡像被切分成多個對象（Object），對象大小通常為4MB，可通過參數調整。
- 對象通過PG（Placement Group）進行管理，PG是邏輯概念，用于數據分布和副本管理。
- 每個PG根據副本數（通常為3副本）將數據分布到不同的OSD上。

RBD卷結構：
- RBD卷的元數據信息存儲在RADOS對象中，包括卷的大小、格式版本、特性標志等。
- RBD卷的數據對象命名規則遵循特定模式，可通過對象名稱模式識別和重組。

三、Ceph恢復過程
1、環境準備與數據備份
A、確認Ceph集群狀態，停止所有可能對存儲進行寫入的操作，避免數據被覆蓋。
B、識別Ceph集群中的所有OSD節點，記錄每個節點的物理位置、存儲設備信息、OSD編號等。
C、北亞企安數據恢復工程師對每個OSD節點上的存儲設備進行只讀模式掛載或底層鏡像備份，確保原始數據安全。
D、備份Ceph集群的配置文件，包括ceph.conf、CRUSH Map等，用于后續分析參考。
E、記錄Ceph集群的版本信息、存儲池配置參數（如pg_num、pgp_num、副本數等），這些信息對恢復至關重要。

北亞企安數據恢復—Ceph數據恢復

2、Ceph元數據分析與重建
A、北亞企安數據恢復工程師分析Ceph Monitor節點上的日志和狀態信息，嘗試提取部分元數據信息。
B、分析CRUSH Map結構，了解數據分布規則，包括故障域設置、權重分配等。
C、根據已知的存儲池配置信息，重建PG到OSD的映射關系。
D、分析OSD節點上的對象存儲結構，識別對象命名規則和存儲格式。
E、通過掃描OSD節點，查找可能保留的元數據對象，嘗試重建部分元數據信息。

北亞企安數據恢復—Ceph數據恢復 北亞企安數據恢復—Ceph數據恢復

3、RBD卷識別與定位
A、根據用戶方提供的RBD卷名稱、大小等信息，北亞企安數據恢復工程師在OSD節點上搜索相關的元數據對象。
B、分析RBD卷的對象命名模式，RBD對象通常以特定前綴命名，如rbd_data、rbd_header等。
C、通過掃描所有OSD節點，查找符合RBD卷特征的對象集合。
D、根據對象的時間戳、大小分布等特征，識別目標RBD卷的數據對象。
E、驗證識別出的對象集合的完整性，確認是否包含完整的RBD卷數據。

北亞企安數據恢復—Ceph數據恢復

4、RBD卷數據重組
A、根據RBD卷的元數據信息，確定卷的大小、對象大小、對象數量等參數。
B、按照RBD對象編號順序，將分散在多個OSD上的對象數據進行重組。
C、處理可能的對象缺失情況，如果存在副本，嘗試從其他OSD節點恢復缺失對象。
D、重組RBD卷的頭部元數據對象，包含卷的配置信息和快照信息。
E、將重組后的RBD卷數據導出為原始鏡像文件，進行完整性校驗。

北亞企安數據恢復—Ceph數據恢復 北亞企安數據恢復—Ceph數據恢復

5、OCFS2文件系統解析與虛擬機磁盤鏡像導出
A、對恢復出的RBD卷鏡像文件進行文件系統類型識別，確認鏡像文件內部使用OCFS2（Oracle Cluster File System 2）文件系統。
B、OCFS2是專為集群環境設計的高性能文件系統，支持多節點并發訪問，具有日志記錄、擴展屬性、配額管理等特性。分析OCFS2文件系統的超級塊結構，獲取文件系統的基本參數信息，包括塊大小、集群大小、節點數量等。
C、解析OCFS2文件系統的目錄結構，OCFS2采用B+樹結構管理目錄項，需要解析目錄索引節點和目錄項信息。
D、解析OCFS2文件系統的文件分配機制，OCFS2使用擴展分配（Extent Allocation）方式管理文件數據塊，需要解析擴展樹結構定位文件數據。
E、讀取OCFS2文件系統中的虛擬機磁盤鏡像文件，OCFS2文件系統可能包含多個文件，需要識別目標虛擬機磁盤鏡像文件（可能是qcow2、raw等格式）。
F、北亞企安數據恢復工程師對OCFS2文件系統進行完整性校驗，檢查文件系統日志的一致性，修復可能存在的元數據錯誤。
G、從OCFS2文件系統中導出虛擬機磁盤鏡像文件，確保導出的鏡像文件完整且可正常訪問。
H、驗證導出的虛擬機磁盤鏡像文件的完整性，確認鏡像文件格式和大小符合預期。

北亞企安數據恢復—Ceph數據恢復

6、XFS文件系統解析與TiDB數據庫文件提取
A、北亞企安數據恢復工程師對導出的虛擬機磁盤鏡像進行分區識別，確定虛擬機磁盤的分區布局和文件系統類型。
B、確認虛擬機磁盤鏡像中使用XFS文件系統，XFS是高性能日志文件系統，具有優秀的擴展性和并發性能，適合存儲大型文件。
C、分析XFS文件系統的超級塊結構，獲取文件系統的基本參數，包括塊大小、分配組（AG）數量、日志大小等。XFS采用分配組（Allocation Group）機制，將文件系統劃分為多個獨立的分配組，每個分配組管理自己的inode和數據塊。
D、解析XFS文件系統的目錄結構，XFS使用B+樹結構管理目錄，需要解析目錄塊和目錄項信息，定位TiDB相關的數據目錄。
E、解析XFS文件系統的inode結構，XFS的inode包含文件的元數據信息，如文件大小、權限、時間戳等，以及指向數據塊的指針。
F、解析XFS文件系統的擴展分配機制，XFS使用擴展（Extent）方式管理文件數據，通過擴展樹（B+樹）快速定位文件數據塊位置。
G、在XFS文件系統中定位TiDB相關的數據目錄，通常包括TiDB Server、TiKV、PD等組件的配置目錄和數據目錄。
H、提取TiDB數據庫相關的所有文件，包括TiKV的數據文件（RocksDB格式的SST文件、WAL日志等）、PD的元數據文件、TiDB的配置文件等。
I、北亞企安數據恢復工程師對提取的TiDB數據庫文件進行完整性校驗，檢查文件大小、文件頭信息等，確認文件是否完整。
J、嘗試將TiDB數據庫文件導入測試環境中，驗證數據庫文件是否可以正常使用。經校驗北亞企安數據恢復工程師發現TiDB數據庫文件存在損壞，無法通過正常方式啟動和使用，需要進入下一步進行底層數據解析和記錄抽取。

北亞企安數據恢復—Ceph數據恢復

7、TiDB數據庫架構分析
TiDB是分布式關系型數據庫，采用計算存儲分離架構：
- TiDB Server：負責SQL解析、查詢優化、事務處理等計算層功能。
- TiKV：分布式鍵值存儲引擎，負責數據存儲，采用Raft協議保證一致性。
- PD（Placement Driver）：集群管理組件，負責元數據管理、調度、時間戳分配等。

TiDB數據存儲機制：
- 數據以Region為單位進行分片存儲，每個Region包含一定范圍的鍵值數據。
- 數據以Key-Value形式存儲在TiKV中，Key包含表ID、行ID等信息。
- 元數據信息存儲在PD中，包括表結構、索引信息、Region分布等。
- TiDB支持MVCC（多版本并發控制），數據可能包含多個版本。

8、TiDB數據文件識別
A、在虛擬機文件系統中定位TiDB相關的數據目錄，通常包括TiDB、TiKV、PD的數據目錄。
B、識別TiDB的數據文件格式，TiKV數據以RocksDB格式存儲，包含SST文件、WAL日志等。
C、分析PD的元數據存儲，PD通常使用etcd存儲元數據信息。
D、識別TiDB的配置文件，了解集群配置、數據目錄路徑、端口信息等。
E、收集TiDB的日志文件，分析數據庫運行狀態和可能的錯誤信息。

9、TiDB數據庫解析
A、分析TiDB的數據文件結構，理解RocksDB的存儲格式和鍵值編碼規則。
B、解析PD的元數據信息，重建數據庫的元數據，包括數據庫列表、表結構、索引定義等。
C、解析TiKV的Region數據，識別每個Region的鍵值范圍和數據內容。
D、根據TiDB的編碼規則，將鍵值數據解析為表記錄格式，包括行數據、列數據等。
E、處理TiDB的MVCC版本信息，提取最新版本的數據記錄。

北亞企安數據恢復—Ceph數據恢復 北亞企安數據恢復—Ceph數據恢復

10、TiDB庫表數據提取
A、根據解析出的元數據信息，列出所有數據庫和表的結構定義。
B、對每個表的數據進行解析，按照表結構定義將鍵值數據轉換為行記錄。
C、處理表的主鍵、唯一索引等約束信息，確保數據完整性。
D、提取表的列數據，包括各種數據類型（整數、字符串、時間、二進制等）的正確解析。
E、處理大對象數據（如BLOB、TEXT類型），確保完整提取。

11、數據導出與驗證
A、將解析出的TiDB數據導出為標準SQL格式或CSV格式，便于后續導入。
B、按照數據庫、表的層次結構組織導出數據，保持數據的邏輯關系。
C、對導出的數據進行完整性校驗，包括記錄數量、數據類型、約束檢查等。
D、生成數據恢復報告，詳細記錄恢復的數據量、表數量、可能的數據缺失情況等。
E、提供數據導入腳本或工具，協助客戶將恢復的數據導入到新的TiDB集群中。

北亞企安數據恢復—Ceph數據恢復

12、數據驗證
A、由用戶主導對恢復的虛擬機數據進行詳細驗證，確認虛擬機可以正常啟動。
B、驗證TiDB數據庫數據的完整性和正確性，包括表結構、記錄數量、數據內容等。
C、對關鍵業務數據進行抽樣驗證，確保數據的準確性和一致性。
D、若驗證有問題，則重復上述相關操作步驟，進行補充恢復。
E、提供數據恢復的詳細文檔和技術支持，協助客戶完成數據遷移和系統重建。

四、Ceph恢復結果
Ceph分布式存儲系統重置后，所有數據丟失，但元信息并沒有被徹底清除，可以通過掃描元信息找回丟失的數據。但由于系統沒有第一時間停機，包括還可能存在的緩沖寫入，導致還是有部分元信息徹底丟失或數據被破壞，恢復出的數據并不是完全正確可用的，因此還需要對其中的TiDB進行解析，提取數據庫表記錄。
北亞企安數據恢復工程師通過結合TiDB中的SST類型的靜態數據文件和raftlog同步日志，對數據文件和日志文件中的數據進行解析合并，成功恢復出了95%以上的數據。

審核編輯 黃宇