谁偷了我的云主机文件？！五大场景避坑措施
发布时间：2021-06-07 10:55:55 所属栏目：云计算 来源：互联网
导读：在云主机的日常运维工作中，我们的工程师经常会遇到用户上报的文件丢失类问题，原因多种多样，这些问题对用户造成了或大或小的困扰。现将其中较典型的场景梳理出来，希望能够帮助大家规避掉这些风险，防止重复踩坑。 场景一：云主机重启后文件丢失 现象： 用
|
在云主机的日常运维工作中，我们的工程师经常会遇到用户上报的文件丢失类问题，原因多种多样，这些问题对用户造成了或大或小的困扰。现将其中较典型的场景梳理出来，希望能够帮助大家规避掉这些风险，防止重复踩坑。
场景一：云主机重启后文件丢失
现象：
用户上报：我的云主机重启后，上面存放的数据怎么没了，是不是云主机有问题啊？！
分析：
与用户沟通后确认，是用户存储在/dev目录下面的文件不见了。很明显，用户数据存储在文件系统类型为tmpfs的/dev目录，tmpfs文件系统默认存储在内存中而非持久化的磁盘，所以重启主机后数据丢失。
解析：
1、何为tmpfs？
tmpfs是一种基于内存的临时文件系统，数据存储在ram中，性能非常好。
2、Linux系统有哪些tmpfs？
/dev、/dev/shm、/sys/fs/cgroup、/run/user/0等，tmpfs文件系统默认为内存总大小的一半。通过df 命令可以看到哪些卷是tmpfs文件系统(Filesystem列显示为tmpfs)：
è°å·äº†æˆ‘的云主机文件？ï¼
建议：
1、tmpfs只用于程序/应用的缓存；
2、不建议将数据放在tmpfs中(除非可承受数据丢失的风险)。
场景二：误执行rm命令
现象：
用户上报：云主机重启后ping不通，或者系统一些服务启动不了，系统关键文件丢失等等。
分析：
1、通过虚拟化的控制台看到，OS卡在开机界面并且报大量的命令不存在；
2、挂载镜像进入系统后，通过less /root/.bash_history查看用户的操作记录，可能看到rm -rf / 、rm -rf 、rm -rf . /*(点号与斜杠之间有空格)、rm -rf ./ 等之类的命令，导致大量的系统目录及文件被删除掉；
3、执行rpm -Va |grep miss 命令校验丢失的系统文件(对于不是通过rpm包安装的文件无法校验)。
建议：
1、慎重使用rm命令，尤其时带上-r 及-f 参数时; 可以加上-i参数进行删除确认；
2、出现误操作时，要第一次时间停掉磁盘的写入，再想办法恢复，避免被删除文件的磁盘空间被覆盖；
3、对于删除的系统文件，可以从其他正常的系统通过拷贝的方式还原；
4、对于一些系统文件或配置文件，还可以通过yum reinstall 包名/yum update 包名 命令重新安装/升级安装来还原。
场景三：文件系统损坏（FIO）
现象：
用户上报：在云主机上运行的 MySQL数据库异常。
分析：
1、通过监控看到云主机的IOWAIT比较高，怀疑和IO限制有关：
è°å·äº†æˆ‘的云主机文件？ï¼
2、放开云主机磁盘限制后，仍然出现异常；MySQL服务不断的在crash，并且备机与主机的现象一样，打印如下日志：
è°å·äº†æˆ‘的云主机文件？ï¼
3、DBA定位，反馈 MySQL的数据文件有问题。
4、在备机上发现，mysql 数据文件所在卷的文件系统有异常并且异常比较严重，在该卷上创建创建文件也会失败：
è°å·äº†æˆ‘的云主机文件？ï¼
5、通过history命令分析root用户操作记录，发现用户使用fio命令对/dev/vdb磁盘(/data卷所在的磁盘)直接进行压测，压测有随机写、顺序写，而不是写/data目录：
è°å·äº†æˆ‘的云主机文件？ï¼
6、MySQL主节点也有执行相同的 fio 操作，由于fio是绕过文件系统层直接对块设备进行操作，磁盘的真实数据已经被覆盖，导致文件已经严重破坏，MySQL数据库无法解析错误的数据文件，从而crash。
7、2台MySQL主机的/data卷数据已经不可靠，需要重新格式化/data卷，并通过备份节点进行恢复数据。
 （编辑：承德站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |