CANARYPWN'S NATÏVE BLOG

修复由误操作导致的分区表重建问题

echo 时一定要检查有几个 '>'
Canarypwn
Aug 21, 2020
It takes 2 minutes to read this article.

起因

在8月初的时候,我接下了学校信息学院某实验室集群助管的工作,上任第一天的工作就是配置管理环境。集群的架构大致是这样,一共是约30台服务器,在上面跑 docker , 映射 ssh 端口,分派给不同的用户使用。除此以外还有两台大容量NFS服务器用于用户存储数据。

我使用了 Portainer.io 进行多机器的 docker 管理。同时用了一个 shell 来完成其它机器运行 portainer.io - agent 以及挂载 nfs 磁盘的操作。

脚本

ERROR

在某一次,由于 NFS 磁盘掉线导致 docker 卡在了 create 的状态上。没有在意,在 nfs 服务器重新上线后重启服务器,发现 docker 掉线了。不过机器足够多,因此把原先的 docker 放在了新的机器上面,这台服务器的问题就被搁置了。

昨天去 SHLUG 的时候见到了 @LightQuantum ,顺便和他说起了这件事情。我们都觉得很奇怪,于是进行排查,发现整个文件系统都被写保护了。最后发现在 /etc/fstab 中是这么写的

10.15.??.??:/mnt/data /mount nfs  0 0
10.15.??.??:/mnt/data /mount1 nfs  0 0

于是想起来脚本中的这一行

echo 'helloworld' > aaaa

只有一个 ‘>’ 是覆盖文件并写入,因此我抹掉了整个分区表

还好大部分服务都在内存中,修复起来稍微容易一些。除了之前被重启过的和为了试验当场重启的。

于是后面两台服务器,首先挂载分区

 mount -o remount,rw /dev/sda3 /

对于其它机器以及这两台服务器,更改其分区文件

/dev/sda3 / ext4 defaults,relatime 0 1
/dev/sda1 /boot ext4 defaults,relatime 0 0
/dev/sda2 none swap defaults 0 0
/dev/sdb1 /data ext4 defaults,relatime 0 0
10.15.??.??:/mnt/data /mount nfs defaults 0 0
10.15.??.??:/mnt/data /mount1 nfs defaults 0 0

加入 defaults 属性也许会让 nfs 运行的更好一些。

这样就修复完成了。