Ceph数据恢复方案–分布式文件系统删除数据的恢复

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

什么是分布式文件系统

分布式文件系统（Distributed File System，DFS）是一种能够在多台计算机之间共享文件存储资源的系统。它将文件存储在多个节点上，这些节点通常是位于不同地理位置的服务器或计算机集群。分布式文件系统的核心目标是提高文件存储的可靠性、可扩展性和性能，同时为用户提供透明的文件访问体验，仿佛文件是存储在单一的本地文件系统中一样。

---

一、Ceph的三种存储结构

对象存储：Ceph 提供 S3 和 Swift 兼容的 RESTful API，用于存储和检索对象数据。
块存储：Ceph 提供块设备接口，支持虚拟机的块存储，如 KVM、OpenStack 等虚拟化平台。
文件系统：Ceph 提供一个 POSIX 兼容的文件系统（CephFS），支持传统的文件存储需求。

本文讲解Ceph中的块存储

二、Ceph中删除数据的恢复提取

1.本次案例情况简介：

环境：基于3台dell存储节点构成的ceph分布式存储系统，搭配kvm虚拟机使用，系统内存有若干台虚拟机，每台节点14块硬盘，由2块480G系统盘+4块1TB的SSD闪存盘+8块12TB的物理盘构成。
故障原因：几个月前误删除一台虚拟机，已联系其他数据恢复公司，删除后的第一时间进行了硬盘镜像，但由于该ceph版本较新，没有任何软件能够支持恢复处理，故一直无法恢复虚拟机内存储的归档文件。

最后经客户同行介绍，与我司取得联系，初步了解事件经过后告知其只需要提供3台节点的所有硬盘镜像即可完成恢复，最终将3台节点的所有硬盘镜送至我司进行处理。

2.数据分析：

2.1：BlueStore架构

用winhex随机查看一块1TB的闪存盘和一块12TB的物理盘，查看关键扇区：得知该ceph分布式存储系统是基于bluestore架构构成的，并使用zookeepr协调，采用的是ceph的块存储。

BlueStore 是 Ceph 的一种存储引擎，设计用于直接管理原始块设备（如 HDD 或 SSD）而不是通过文件系统来存储数据。与传统的基于文件系统的存储引擎（如 Filestore）相比，BlueStore 提供了更高的性能和更高效的存储利用率。
由于我司对ceph数据存储的16进制结构十分了解，（可以使用winhex直接手动提取数据文件），并有多起类似的数据恢复的成功案例，故直接开始提取数据。

2.2分布式存储中元数据概述

提取之前，首先要科普1下元数据的作用，方便大家理解：

在分布式存储系统中，元数据是系统运转的关键，它不仅支撑了数据的存储、访问、复制和恢复，还在负载均衡、安全管理、去重等方面发挥了重要作用。由于分布式存储系统的复杂性和规模性，元数据的管理和优化对系统的性能、可靠性和可扩展性有着直接影响。
大概归类为：

数据定位与访问：
在分布式存储系统中，数据通常被拆分成多个块，并分布在不同的存储节点上。元数据用于记录每个数据块的位置、存储节点的地址、块的大小、复制数量等信息。
如：当客户端请求访问某一数据时，系统首先查找相关的元数据，以确定数据块所在的节点，然后从这些节点读取数据。比如我司曾处理过的HDFS分布式存储中，NameNode 负责管理元数据，记录文件的分块信息以及这些块所在的 DataNode。当用户请求文件时，NameNode 提供数据块的位置，客户端再从对应的 DataNode 中获取数据。

数据复制与一致性：
分布式存储系统为了确保数据的可靠性和可用性，通常会将数据复制到多个节点。元数据在这种场景中记录了每个数据块的副本数量、位置以及版本信息。
如：当一个数据文件被更新时，元数据会记录新的ID号，并触发其他数据文件的更新。如在本作的Ceph分布式存储系统中，Ceph Monitor 维护了集群的元数据，包括存储池、数据副本位置和状态等。

故障检测与恢复：
分布式存储系统需要处理节点故障、数据损坏等问题。元数据记录了哪些节点存储了哪些数据块，因此，当某个节点发生故障时，系统可以利用元数据来重新分配数据块，确保数据的完整性。

如：当某个节点不可用时，系统可以通过元数据识别丢失的数据块，并从其他副本中恢复这些数据。例如，在 Amazon S3云存储中，元数据会跟踪每个对象的存储位置和状态，如果某个存储节点失效，系统可以自动从其他节点恢复数据。

负载均衡与扩展：
为了保证系统的性能，需要对存储节点的负载进行均衡，并且系统可能需要随着数据量的增长进行扩展。元数据可以提供关于当前数据分布、节点负载的统计信息，以帮助系统做出负载均衡和扩展决策。

如：元数据帮助系统决定新数据应该存放在哪些节点上，以及何时将某些数据迁移到其他节点以平衡负载。比如在老版本的ceph分布式存储系统中，当时没有bluestore架构，元数据可以让系统决定将新数据写入哪个XFS分区中，以避免某些节点过载。

元数据总结：元数据=数据标签，分布式系统中的元数据大致等于（不限于）windows平台中NTFS文件系统中的MFT、linux平台中EXT4、XFS等多种文件系统中的index，只不过在分布式存储系统中我们称为"元数据"

2.3提取元数据

提取元数据中我司内部定义的能够支持本次数据恢复提取的三种类型（仅代表我司内部拟定的统称，与外界同名的类型存在一定偏差），并创建数据库进行存储：
meta_chunk：元数据自身空间分布信息
meta_data：元数据本身
meta_id：元数据内部通信

2.3.1：获取12个SSD闪存盘的“OSD”位图：在当前ceph分布式存储系统中：除系统盘外，每个成员盘为1个OSD块。只不过这个块过于巨大（大块），即每个物理盘的数据位图，然后从12块闪存盘中分离出元数据存储在哪些小块内的meta_chunk信息。
在块存储的Ceph中，对于底层来说，OSD的含义和CephFS中差异较大，本案例为块存储案例，故加“”

2.3.2：获取meta_data

根据获取的meta_chunk信息，提取出现有的完整的元数据，再根据现有元数据特征（多特征），获取所有能够提取的元数据，我们依据meta_data将元数据按记录的数据类型再次归类（本次案例只列出3种对本次恢复有关的类型：文件名、目录、osd空间分配）

2.3.4.元数据整理

依据meta_data内的meta_id的信息记录，分离现有数据和丢失数据的meta_data（包含当前持久化之前的曾经存在过的瞬时状态的数据）

2.3.5.计算数据地址

将元数据重组，解析meta_data内键值记录的字节流，获得数据的OSD小块ID，但由于元数据数量过于庞大，只能通过自建一个“元数据数据库”来存储和管理这些信息

3.数据恢复提取

3.1：将meta_data与osd小块进行关联，获取meta_data内记录的存储结构，本次案例获取为4+2结构，即一份数据切割为4份存储，再配两份校验，即4+2，有些厂商对客户也称为“三副本”
这里小编也觉得奇怪，按理说三副本是指的三份文件副本1+1+1的方式，但是在实际遇到的有些客户说厂家给他们说的三副本，但其实小编看到是4+2。

3.2：从KVM的日志中获取虚拟机的唯一识别码，与meta_data关联，锁定所需恢复的虚拟机名。

3.3：通过自建的“元数据数据库”引导提取对应的每个osd小块，然后按照4+2组合成虚拟磁盘文件的碎片，再通过大量碎片的组合，最终形成完整的虚拟磁盘文件。

3.4：使用winhex或常见的数据恢复工具对虚拟磁盘文件进行展开，导出里面的数据或生成新的虚拟磁盘文件交付给客户。

总结

由于时间关系，本文写的相对简单，之后小编闲下来了会进行详细的补充，因此这里也简单写了恢复工具的demo，有需要的话可以自行下载尝试：恢复工具Demo下载