Ceph存储池数据恢复完整指南

Ceph是目前最流行的开源分布式存储系统之一，提供对象存储（RGW）、块存储（RBD）和文件系统（CephFS）三种存储接口。然而，Ceph集群故障可能导致存储池数据丢失。本文将详细介绍Ceph各类故障场景下的数据恢复方法。

一、Ceph数据存储架构

1.1 Ceph数据分布机制

Ceph使用CRUSH算法将数据分布到集群中：

客户端写入 → Monitor获取CRUSH Map → 计算数据位置 → 写入对应OSD

关键概念：

OSD（Object Storage Daemon）： 实际存储数据的守护进程
PG（Placement Group）： 数据分组的逻辑单元
Pool（存储池）： 逻辑存储容器，包含多个PG
CRUSH Map： 数据分布算法的拓扑图

1.2 数据冗余机制

Ceph通过副本（Replication）或纠删码（Erasure Code）保护数据：

副本模式：

默认3副本，数据写3份到不同OSD
可承受2个OSD同时故障
恢复速度快，但空间利用率低（33%）

纠删码模式：

类似RAID 5/6，如k=2, m=1（2个数据块+1个校验块）
空间利用率高（67%）
恢复需要计算，速度较慢

1.3 常见故障类型

OSD故障： 单个或多个OSD离线
PG降级： Placement Group状态异常
Monitor故障： 集群脑裂或Monitor数据损坏
存储池损坏： Pool元数据丢失或损坏
CRUSH Map损坏： 数据分布规则丢失
多节点故障： 超过冗余能力的节点同时故障

二、故障诊断与状态评估

2.1 检查集群健康状态

# 查看集群整体状态
ceph health detail

# 查看集群状态摘要
ceph -s

# 查看OSD状态
ceph osd tree

# 查看PG状态
ceph pg stat

# 查看存储池状态
ceph osd pool ls detail

2.2 常见健康状态解读

HEALTH_OK： 集群正常，所有PG处于active+clean状态

HEALTH_WARN： 警告状态，可能原因：

时钟不同步
OSD接近满容量
PG数量不均衡
副本数不足

HEALTH_ERR： 错误状态，可能原因：

OSD down数量超过容忍范围
PG处于inactive状态
数据不一致
Monitor quorum丢失

2.3 PG状态详解

# 查看所有异常PG
ceph pg dump_stuck unclean
ceph pg dump_stuck inactive
ceph pg dump_stuck stale

# 查看特定PG详情
ceph pg  query

常见PG状态：

active+clean：正常
active+degraded：副本不足，正在恢复
active+recovering：正在恢复数据
peering：正在协商数据位置
incomplete：数据不完整，需要手动干预
stale：PG主OSD无响应

三、OSD故障恢复

3.1 单个OSD故障

场景： 一个OSD进程崩溃或磁盘故障

恢复步骤：

# 1. 检查OSD状态
ceph osd tree | grep osd.X

# 2. 如果OSD标记为down，尝试重启
systemctl restart ceph-osd@X

# 3. 如果磁盘故障，更换磁盘后重建OSD
# 标记旧OSD为out
ceph osd out osd.X

# 删除旧OSD
ceph osd purge osd.X --yes-i-really-mean-it

# 准备新磁盘
ceph-volume lvm create --data /dev/sdX

# 4. 等待数据自动重新平衡
ceph -w

3.2 多个OSD同时故障

场景： 多个OSD同时离线，超过副本容忍范围

恢复步骤：

# 1. 评估故障范围
ceph osd tree | grep down

# 2. 尝试恢复OSD
for osd_id in $(ceph osd tree | grep down | awk '{print $1}'); do
    echo "恢复 OSD.$osd_id"
    systemctl restart ceph-osd@$osd_id
done

# 3. 如果OSD无法启动，检查日志
journalctl -u ceph-osd@X --since "1 hour ago"

# 4. 如果磁盘损坏，需要重建
# 先标记为lost（谨慎操作！）
ceph osd lost osd.X --yes-i-really-mean-it

# 5. 强制恢复PG（如果数据不可用）
ceph pg force_recovery

3.3 OSD数据损坏

场景： OSD磁盘数据损坏但磁盘本身可用

恢复步骤：

# 1. 停止故障OSD
systemctl stop ceph-osd@X

# 2. 检查文件系统
xfs_repair /dev/sdX1  # 如果是XFS
# 或
fsck.ext4 /dev/sdX1   # 如果是ext4

# 3. 如果文件系统无法修复，使用数据恢复工具
ddrescue /dev/sdX /backup/osd_X.img /backup/osd_X.log

# 4. 从镜像中尝试恢复数据
# 挂载镜像
mount -o ro /backup/osd_X.img /mnt/osd_recovery

# 5. 手动提取对象数据
# Ceph对象存储在 current/ 目录下
find /mnt/osd_recovery/current/ -name "*.data" -exec cp {} /recovery/ \;

# 6. 重建OSD并让集群自动恢复
ceph-volume lvm create --data /dev/sdX

四、PG（Placement Group）故障恢复

4.1 PG处于incomplete状态

场景： PG数据不完整，无法自动恢复

恢复步骤：

# 1. 查看incomplete的PG
ceph pg dump_stuck incomplete

# 2. 查询PG详情
ceph pg  query

# 3. 尝试标记为lost（会丢失该PG的数据）
ceph pg mark_unfound_lost revert 

# 或者强制接受当前状态
ceph pg  mark_complete

# 4. 如果知道哪个OSD有最新数据
ceph pg  mark_complete --force

4.2 PG peering失败

场景： PG无法完成peering过程

恢复步骤：

# 1. 查看peering失败的PG
ceph pg dump_stuck stale

# 2. 重置PG状态
ceph pg  query  # 查看详细信息

# 3. 强制重新peering
ceph pg force_peer 

# 4. 如果仍然失败，可能需要手动干预
# 找到PG的所有副本位置
ceph pg map 

# 5. 检查相关OSD是否正常
ceph osd find

4.3 PG数据不一致

场景： PG副本之间数据不一致

恢复步骤：

# 1. 查看不一致的PG
ceph pg dump_stuck inconsistent

# 2. 执行深度scrub
ceph pg deep-scrub 

# 3. 查看scrub结果
ceph health detail

# 4. 修复不一致
ceph pg repair 

# 5. 如果自动修复失败，手动选择权威副本
ceph pg  mark_complete --force

五、存储池（Pool）故障恢复

5.1 存储池被误删

场景： 使用ceph osd pool delete误删了存储池

恢复方法：

方法一：从备份恢复（如果有）

# 1. 如果启用了pool快照
ceph osd pool ls
# 如果pool还在快照中，可以从快照恢复

# 2. 从RBD快照恢复（如果是RBD池）
rbd snap ls poolname/image
rbd snap rollback poolname/image@snap_name

# 3. 从RGW备份恢复（如果是对象存储池）
# 使用radosgw-admin从备份恢复元数据
radosgw-admin metadata get bucket: --infile backup.json

方法二：底层数据恢复

# 1. 停止所有写入操作
ceph osd set noout
ceph osd set norecover

# 2. 找到原pool的PG数据
# Pool删除后，PG数据仍在OSD中，但元数据丢失

# 3. 重新创建同名pool（使用相同参数）
ceph osd pool create poolname 128 128 replicated
ceph osd pool set poolname size 3

# 4. 等待PG重新分布
# 注意：旧数据可能已被覆盖，恢复不保证完整

# 5. 检查数据完整性
rados -p poolname ls

5.2 存储池元数据损坏

场景： Pool的CRUSH规则或元数据损坏

恢复步骤：

# 1. 导出当前CRUSH map
ceph osd getcrushmap -o crush.map
crushtool -d crush.map -o crush.map.txt

# 2. 检查CRUSH规则
ceph osd crush rule ls
ceph osd crush rule dump

# 3. 如果CRUSH map损坏，从Monitor恢复
# Monitor会保存CRUSH map的历史版本
ceph osd getcrushmap -o crush.map.backup

# 4. 修复并重新导入
crushtool -c crush.map.txt -o crush.map.fixed
ceph osd setcrushmap -i crush.map.fixed

# 5. 验证数据分布
ceph osd pool get poolname crush_rule

5.3 存储池容量满导致数据不可用

场景： Pool达到full ratio，所有写入被阻止

恢复步骤：

# 1. 临时提高full ratio阈值
ceph osd set-full-ratio 0.97

# 2. 删除不必要的数据
rados -p poolname rm 

# 3. 或者扩容pool
ceph osd pool set poolname pg_num 256

# 4. 添加新OSD
# （添加新硬件后）
ceph osd create
ceph-volume lvm create --data /dev/sdX

# 5. 恢复正常阈值
ceph osd set-full-ratio 0.95

六、Monitor故障恢复

6.1 单个Monitor故障

# 1. 检查Monitor状态
ceph mon stat
ceph mon dump

# 2. 重启故障Monitor
systemctl restart ceph-mon@

# 3. 如果Monitor数据损坏，从其他Monitor同步
# 停止故障Monitor
systemctl stop ceph-mon@

# 备份损坏的数据
mv /var/lib/ceph/mon/ceph- /var/lib/ceph/mon/ceph-.bak

# 从其他Monitor复制数据
scp -r /var/lib/ceph/mon/ceph-/* \
  :/var/lib/ceph/mon/ceph-/

# 重启Monitor
systemctl start ceph-mon@

6.2 Monitor Quorum丢失

场景： 多数Monitor故障，集群无法形成quorum

恢复步骤：

# 1. 找到最新的Monitor数据
# 在所有Monitor节点上检查
ls -la /var/lib/ceph/mon/ceph-*/store.db/

# 2. 选择数据最新的Monitor
# 查看commit序列号
cat /var/lib/ceph/mon/ceph-/store.db/CURRENT

# 3. 提取Monitor map
ceph-mon -i  --extract-monmap /tmp/monmap

# 4. 重建Monitor
systemctl stop ceph-mon@
ceph-mon -i  --mkfs --monmap /tmp/monmap --keyring /etc/ceph/ceph.client.admin.keyring
systemctl start ceph-mon@

# 5. 验证quorum
ceph mon stat

七、专业数据恢复工具

7.1 Ceph原生工具

| 工具 | 用途 |

|------|------|

| rados | 直接操作RADOS对象 |

| rbd | RBD块设备管理 |

| radosgw-admin | RGW对象存储管理 |

| ceph-objectstore-tool | OSD底层数据操作 |

| ceph-bluestore-tool | BlueStore底层修复 |

7.2 底层数据恢复

# 使用ceph-objectstore-tool恢复对象
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-X \
  --op list \
  --pgid 

# 导出特定对象
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-X \
  --op export \
  --pgid  \
  --object  \
  --file /recovery/object.dat

# 使用ceph-bluestore-tool修复
ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-X

7.3 第三方工具

Ceph Recovery Tool by Kloudrrd： 专业Ceph数据恢复
SalvageData Ceph Recovery： 商业Ceph恢复服务
Ontrack Ceph Recovery： 企业级恢复方案

八、预防措施

8.1 集群设计建议

# ceph.conf 关键配置
[global]
# 设置合理的副本数
osd pool default size = 3
osd pool default min size = 2

# 设置合理的full ratio
mon osd full ratio = 0.95
mon osd nearfull ratio = 0.85

# 启用scrub自动检查
osd scrub min interval = 86400
osd scrub max interval = 604800

# 启用自动恢复
osd max backfills = 1
osd recovery max active = 3

8.2 监控告警

# 使用Prometheus + Grafana监控Ceph
# 安装ceph-exporter
ceph mgr module enable prometheus

# 配置告警规则
# 关键告警：
# - OSD down
# - PG degraded
# - Pool near full
# - Monitor quorum warning

8.3 定期维护

#!/bin/bash
# Ceph集群日常巡检脚本

echo "=== 集群健康状态 ==="
ceph health detail

echo "=== OSD状态 ==="
ceph osd stat

echo "=== PG状态 ==="
ceph pg stat

echo "=== 存储池使用率 ==="
ceph osd df

echo "=== 异常PG ==="
ceph pg dump_stuck unclean
ceph pg dump_stuck inactive

echo "=== 慢请求 ==="
ceph osd perf

8.4 备份策略

# RBD快照备份
rbd snap create poolname/image@backup-$(date +%Y%m%d)

# RGW元数据备份
radosgw-admin metadata list bucket | while read bucket; do
    radosgw-admin metadata get bucket:$bucket > /backup/bucket_$bucket.json
done

# Monitor数据备份
ceph mon getmap -o /backup/monmap-$(date +%Y%m%d)

# CRUSH map备份
ceph osd getcrushmap -o /backup/crushmap-$(date +%Y%m%d)

九、总结

Ceph存储池数据恢复的关键要点：

快速诊断： 准确判断故障类型和范围
分级处理： OSD故障 < PG故障 < Pool故障 < Monitor故障
保护现场： 恢复前先备份，避免二次损坏
利用冗余： 充分利用Ceph的副本和纠删码机制
预防为主： 监控告警+定期维护+备份策略

Ceph作为复杂的分布式系统，故障恢复需要深入理解其架构原理。对于关键业务数据，建议在专业工程师指导下进行恢复操作，或直接联系专业数据恢复服务商。

---

本文更新于2026年7月6日，适用于Ceph Pacific (16.2.x)、Quincy (17.2.x) 和 Reef (18.2.x) 版本。

Ceph存储池数据恢复完整指南

一、Ceph数据存储架构

1.1 Ceph数据分布机制

1.2 数据冗余机制

1.3 常见故障类型

二、故障诊断与状态评估

2.1 检查集群健康状态

2.2 常见健康状态解读

2.3 PG状态详解

三、OSD故障恢复

3.1 单个OSD故障

3.2 多个OSD同时故障

3.3 OSD数据损坏

四、PG（Placement Group）故障恢复

4.1 PG处于incomplete状态

4.2 PG peering失败

4.3 PG数据不一致

五、存储池（Pool）故障恢复

5.1 存储池被误删

5.2 存储池元数据损坏

5.3 存储池容量满导致数据不可用

六、Monitor故障恢复

6.1 单个Monitor故障

6.2 Monitor Quorum丢失

七、专业数据恢复工具

7.1 Ceph原生工具

7.2 底层数据恢复

7.3 第三方工具

八、预防措施

8.1 集群设计建议

8.2 监控告警

8.3 定期维护

8.4 备份策略

九、总结

数据丢失不要慌，专业工具帮您恢复

相关文章推荐