cephfs元数据池故障的恢复

前言

cephfs 在L版本已经比较稳定了，这个稳定的意义个人觉得是在其故障恢复方面的成熟，一个文件系统可恢复是其稳定必须具备的属性，本篇就是根据官网的文档来实践下这个恢复的过程

实践过程

部署一个ceph Luminous集群

[root@lab102 ~]# ceph -v
ceph version 12.2.5 (cad919881333ac92274171586c827e01f554a70a) luminous (stable)

创建filestore

ceph-deploy osd create  lab102  --filestore  --data /dev/sdb1  --journal /dev/sdb2

这里想用filestore进行测试就按上面的方法去创建osd即可

传入测试数据

• doc
• pic
• vidio
  这里提供下载链接

链接：https://pan.baidu.com/s/19tlFi4butA2WjnPAdNEMwg 密码：ugjo

这个是网上下载的模板的数据，方便进行真实的文件的模拟，dd产生的是空文件，有的时候会影响到测试

需要更多的测试文档推荐可以从下面网站下载

视频下载：

https://videos.pexels.com/popular-videos

图片下载：

https://www.pexels.com/

文档下载：

http://office.mmais.com.cn/Template/Home.shtml

元数据模拟故障

跟元数据相关的故障无非就是mds无法启动，或者元数据pg损坏了，这里我们模拟的比较极端的情况，把metadata的元数据对象全部清空掉，这个基本能覆盖到最严重的故障了，数据的损坏不在元数据损坏的范畴

清空元数据存储池

for object in `rados -p metadata ls`;do rados -p metadata rm $object;done

重启下mds进程，应该mds是无法恢复正常的

cluster:
    id:     9ec7768a-5e7c-4f8e-8a85-89895e338cca
    health: HEALTH_ERR
            1 filesystem is degraded
            1 mds daemon damaged
            too few PGs per OSD (16 < min 30)
 
  services:
    mon: 1 daemons, quorum lab102
    mgr: lab102(active)
    mds: ceph-0/1/1 up , 1 up:standby, 1 damaged
    osd: 1 osds: 1 up, 1 in

准备开始我们的修复过程

元数据故障恢复

设置允许多文件系统

ceph fs flag set enable_multiple true --yes-i-really-mean-it

创建一个新的元数据池，这里是为了不去动原来的metadata的数据，以免损坏原来的元数据

ceph osd pool create recovery 8

将老的存储池data和新的元数据池recovery关联起来并且创建一个新的recovery-fs

[root@lab102 ~]# ceph fs new recovery-fs recovery data --allow-dangerous-metadata-overlay
new fs with metadata pool 3 and data pool 2

做下新的文件系统的初始化相关工作

[root@lab102 ~]#cephfs-data-scan init --force-init --filesystem recovery-fs --alternate-pool recovery

reset下新的fs

[root@lab102 ~]#ceph fs reset recovery-fs --yes-i-really-mean-it
[root@lab102 ~]#cephfs-table-tool recovery-fs:all reset session
[root@lab102 ~]#cephfs-table-tool recovery-fs:all reset snap
[root@lab102 ~]#cephfs-table-tool recovery-fs:all reset inode

做相关的恢复

[root@lab102 ~]# cephfs-data-scan scan_extents --force-pool --alternate-pool recovery --filesystem ceph  data
[root@lab102 ~]# cephfs-data-scan scan_inodes --alternate-pool recovery --filesystem ceph --force-corrupt --force-init data
[root@lab102 ~]# cephfs-data-scan scan_links --filesystem recovery-fs

[root@lab102 ~]# systemctl start ceph-mds@lab102
等待mds active 以后再继续下面操作
[root@lab102 ~]# ceph daemon mds.lab102 scrub_path / recursive repair

设置成默认的fs

[root@lab102 ~]# ceph fs set-default recovery-fs

挂载检查数据

[root@lab102 ~]#  mount -t ceph 192.168.19.102:/ /mnt
[root@lab102 ~]# ll /mnt
total 0
drwxr-xr-x 1 root root 1 Jan  1  1970 lost+found
[root@lab102 ~]# ll /mnt/lost+found/
total 226986
-r-x------ 1 root root   569306 May 25 16:16 10000000001
-r-x------ 1 root root 16240627 May 25 16:16 10000000002
-r-x------ 1 root root  1356367 May 25 16:16 10000000003
-r-x------ 1 root root   137729 May 25 16:16 10000000004
-r-x------ 1 root root   155163 May 25 16:16 10000000005
-r-x------ 1 root root   118909 May 25 16:16 10000000006
-r-x------ 1 root root  1587656 May 25 16:16 10000000007
-r-x------ 1 root root   252705 May 25 16:16 10000000008
-r-x------ 1 root root  1825192 May 25 16:16 10000000009
-r-x------ 1 root root   156990 May 25 16:16 1000000000a
-r-x------ 1 root root  3493435 May 25 16:16 1000000000b
-r-x------ 1 root root   342390 May 25 16:16 1000000000c
-r-x------ 1 root root  1172247 May 25 16:16 1000000000d
-r-x------ 1 root root  2516169 May 25 16:16 1000000000e
-r-x------ 1 root root  3218770 May 25 16:16 1000000000f
-r-x------ 1 root root   592729 May 25 16:16 10000000010

可以看到在lost+found里面就有数据了

[root@lab102 ~]# file /mnt/lost+found/10000000010 
/mnt/lost+found/10000000010: Microsoft PowerPoint 2007+
[root@lab102 ~]# file /mnt/lost+found/10000000011
/mnt/lost+found/10000000011: Microsoft Word 2007+
[root@lab102 ~]# file /mnt/lost+found/10000000012
/mnt/lost+found/10000000012: Microsoft Word 2007+
[root@lab102 ~]# file /mnt/lost+found/10000000013
/mnt/lost+found/10000000013: Microsoft PowerPoint 2007+

这个生成的文件名称就是实际文件存储的数据的prifix，也就是通过原始inode进行的运算得到的

如果提前备份好了原始的元数据信息

[root@lab102 ~]# ceph daemon mds.lab102 dump cache > /tmp/mdscache

那么可以比较轻松的找到丢失的文件

总结

在我另外一篇文章当中已经写过了，通过文件的inode可以把文件跟后台的对象结合起来，在以前我的恢复的思路是，把后台的对象全部抓出来，然后自己手动去对对象进行拼接，实际是数据存在的情况下，反向把文件重新link到一个路径，这个是官方提供的的恢复方法，mds最大的担心就是mds自身的元数据的损坏可能引起整个文件系统的崩溃，而现在，基本上只要data的数据还在的话，就不用担心数据丢掉，即使文件路径信息没有了，但是文件还在

通过备份mds cache可以把文件名称，路径，大小和inode关联起来，而恢复的数据是对象前缀，也就是备份好了mds cache 就可以把整个文件信息串联起来了

虽然cephfs的故障不是常发生，但是万一呢

后续准备带来一篇关于cephfs从挂载点误删除数据后的数据恢复的方案，这个目前已经进行了少量文件的恢复试验了，等后续进行大量文件删除的恢复后，再进行分享

参考文档

disaster-recovery

变更记录

Why	Who	When
创建	武汉-运维-磨渣	2018-05-29