ceph mds dmaged造成cephfs崩掉的灾难性恢复
**问题：**未知原因，有可能是服务器搬离机柜造成的。也有可能是osd crash出错，数据丢失，cephfs无法提供服务，经查，是没有active的mds了，所有的mds都是standby状态，并且有两个是dmaged的状态。
[root@node83 .ceph-cluster]# ceph health detail
HEALTH_ERR 2 filesystems are degraded; 1 filesystem has a failed mds daemon; 2 filesystems are offline; 1 mds daemon damaged; insufficient standby MDS daemoavailable; application not enabled on 1 pool(s); 6 daemons have recently crashed; mons node82,node83,node84 are low on available space
FS_DEGRADED 2 filesystems are degraded
fs AI_Spacefs is degraded
fs recovery-fs is degraded
fs AI_Spacefs is offline because no MDS is active for it..
MDS_DAMAGE 1 mds daemon damaged
fs AI_Spacefs mds.0 is damaged
解决：两种方法:
-
方法一：
#ceph mds repaired AI_Spacefs:0 #ceph mds repaired AI_Spacefs:1此方法一般情况下是好使，当有osd stuck的状态时也会失效。这个时候要重启osd,若未发现stuck就要手动触发数据迁移把stuck的osd暴露出来。然后再执行上面的操作。
经测试，有两次都是通过上述方法解决问题的。 -
方法二：
这次问题要严重的多，所有的mds都没有active的状态，造成元数据无法恢复，方法一失效，所以此时需要放弃原来的cephfs，重建构建基于原来data池生成新的cephfs.
元数据故障恢复
设置允许多文件系统
ceph fs flag set enable_multiple true --yes-i-really-mean-it
创建一个新的元数据池，这里是为了不去动原来的metadata的数据，以免损坏原来的元数据
ceph osd pool create recovery 8
将老的存储池data和新的元数据池recovery关联起来并且创建一个新的recovery-fs
ceph fs new recovery-fs recovery AI_Spacefs_data --allow-dangerous-metadata-overlay
做下新的文件系统的初始化相关工作
#cephfs-data-scan init --force-init --filesystem recovery-fs --alternate-pool recovery
2020-03-18T16:22:50.508+0800 7f4a11a1d700 -1 NetHandler create_socket couldn't create socket (97) Address family not supported by protocol
出现上述的错误可以忽略进行下一步。
reset下新的fs
#ceph fs reset recovery-fs --yes-i-really-mean-it
若失败，要把所有mds fail掉或者stop掉，再快速执行上面命令。
#cephfs-table-tool recovery-fs:all reset session
#cephfs-table-tool recovery-fs:all reset snap
#cephfs-table-tool recovery-fs:all reset inode
出现Address family not supported by protocol的错误忽略掉
做相关的恢复
做下一步之前确保新建的recovery-fs没有active的mds,有则stop掉，不然该mds容易crashed。
#cephfs-data-scan scan_extents --force-pool --alternate-pool recovery --filesystem AI_Spacefs AI_Spacefs_data
#cephfs-data-scan scan_inodes --alternate-pool recovery --filesystem AI_Spacefs -force-corrupt --force-init AI_Spacefs_data
#cephfs-data-scan scan_inodes --alternate-pool recovery --filesystem AI_Spacefs --force-corrupt --force-init AI_Spacefs_data
#cephfs-data-scan scan_links --filesystem recovery-fs
出现Address family not supported by protocol的错误忽略掉
# systemctl start ceph-mds@node82
等待mds active 以后再继续下面操作
# ceph daemon mds.node82 scrub_path / recursive repair
事实上上面这一步并没有操作数据就已经恢复了。
设置成默认的fs
# ceph fs set-default recovery-fs
挂载检查数据
[root@node82 lyf3]# ls
DATASET lost+found SYSTEM USER
[root@node82 lyf3]# ll lost+found/
total 1
-r-x------ 1 root root 237 Mar 11 13:21 1000172efb8
可以看到在lost+found里面就有数据了这个生成的文件名称就是实际文件存储的数据的prifix，也就是通过原始inode进行的运算得到的。
如果提前备份好了原始的元数据信息
# ceph daemon mds.node82 dump cache > /tmp/mdscache
那么可以比较轻松的找到丢失的文件
原作者总结
通过文件的inode可以把文件跟后台的对象结合起来，在以前我的恢复的思路是，把后台的对象全部抓出来，然后自己手动去对对象进行拼接，实际是数据存在的情况下，反向把文件重新link到一个路径，这个是官方提供的的恢复方法，mds最大的担心就是mds自身的元数据的损坏可能引起整个文件系统的崩溃，而现在，基本上只要data的数据还在的话，就不用担心数据丢掉，即使文件路径信息没有了，但是文件还在
通过备份mds cache可以把文件名称，路径，大小和inode关联起来，而恢复的数据是对象前缀，也就是备份好了mds cache 就可以把整个文件信息串联起来了
虽然cephfs的故障不是常发生，但是万一呢
后续准备带来一篇关于cephfs从挂载点误删除数据后的数据恢复的方案，这个目前已经进行了少量文件的恢复试验了，等后续进行大量文件删除的恢复后，再进行分享
参考文档：
https://ceph.com/planet/cephfs%E5%85%83%E6%95%B0%E6%8D%AE%E6%B1%A0%E6%95%85%E9%9A%9C%E7%9A%84%E6%81%A2%E5%A4%8D/
https://docs.ceph.com/docs/luminous/cephfs/disaster-recovery/
https://blog.csdn.net/mailjoin/article/details/79694965