云服务器可以清除哪一些文件,谁偷了我的云主机文件?!五大场景避坑指南

39c41ac2a53628a7c71b6566ba85cff3.png

在云主机的日常运维工作中,我们的工程师经常会遇到用户上报的文件丢失类问题,原因多种多样,这些问题对用户造成了或大或小的困扰。现将其中较典型的场景梳理出来,希望能够帮助大家规避掉这些风险,防止重复踩坑。

场景一:云主机重启后文件丢失

现象:

用户上报:我的云主机重启后,上面存放的数据怎么没了,是不是云主机有问题啊?!

分析:

与用户沟通后确认,是用户存储在/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):

67e1d5c0e34a4b90610659589859e2b9.png

建议:

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限制有关:

9c921d8603295bfdad5781875b41badf.png

2、放开云主机磁盘限制后,仍然出现异常;MySQL服务不断的在crash,并且备机与主机的现象一样,打印如下日志:

2ec5acef4902574bf1daef15ff162d1f.png

3、DBA定位,反馈 MySQL的数据文件有问题。

4、在备机上发现,mysql 数据文件所在卷的文件系统有异常并且异常比较严重,在该卷上创建创建文件也会失败:

9de503ee141005e6bdb85ed2f0f44857.png

5、通过history命令分析root用户操作记录,发现用户使用fio命令对/dev/vdb磁盘(/data卷所在的磁盘)直接进行压测,压测有随机写、顺序写,而不是写/data目录:

cd4bfb59be7c2a066374462fd5a51a1d.png

6、MySQL主节点也有执行相同的 fio 操作,由于fio是绕过文件系统层直接对块设备进行操作,磁盘的真实数据已经被覆盖,导致文件已经严重破坏,MySQL数据库无法解析错误的数据文件,从而crash。

7、2台MySQL主机的/data卷数据已经不可靠,需要重新格式化/data卷,并通过备份节点进行恢复数据。

建议:

1、生产环境要慎用 fio 工具,应该在上线前进行压测;

2、使用 fio 命令时,—filename 参数一定不要直接指定块设备(如/dev/sda、/dev/vdb等),而要指定一个普通文件,可以先touch一个空文件,再指定这个文件名。

efc5c4b2950701adac38d751b3c62960.png

测试完成后,再删除该文件即可,不然会占用 -size 参数所指定的空间。

场景四:文件系统损坏(DD)

现象:

用户上报:云主机文件访问异常。

分析:

1、云主机数据卷上的文件无访问,并且ls也异常,报【Structure needs cleaning】错误:

4845dd45685847fa6a6b9bb3f4aaf1e3.png

2、通过dmesg及 /var/log/messages日志文件看到有大量xfs文件系统的报错:

d85c1c2ad81dc50adcbfe485ee3d2a59.png

3、通过history命令分析root用户操作记录,发现root用户有使用dd 命令对 /dev/vdb 磁盘(/data卷所在的磁盘)直接进行压测,对/dev/vdb磁盘写零:

c4c530d15e424aa59b5a42df2e33d3c5.png

建议:

1、生产环境要慎用 dd 工具,应该在上线前进行压测;

2、使用 dd 命令时 of 参数一定不要直接指定块设备(如/dev/sda、/dev/vdb等)要指定一个普通文件。

如下:

b0ad9322b5168a8955d951fe1b94a263.png

场景五:数据盘被误删除

现象:

用户上报:云磁盘被误删除。

分析:

1、登录云门户查看云磁盘的删除时间,由于云资源是延迟一段时间再删除的,短时间内还可以找回被删除的资源:

a351f78df77a56354a5963b38bea7b44.png

2、在虚拟化控制台,确认磁盘是否已经删除(State状态要为Ready):

8b9f32029ab14fe032e3747b8a6a333e.png

3、如果尚未删除,可以将云磁盘重新attach到主机;

4、在云门户同步云磁盘信息。

建议:

1、云磁盘的删除操作请谨慎,误删后数据真得无法恢复;

2、删除操作前先确认:

A. 在主机上通过lsof -n、df  -h、lvs/pvs/vgs、lsblk等工具确认磁盘是否在使用、是否用于扩容的卷;

B. 对于非用于扩容的卷,确认后,先umount卷、并且清除/etc/fstab中挂载点的信息;

C. 用于扩容的卷无法直接删除,删除会导致原卷出现异常;

3、出现误操作时,要第一时间联系恢复,否则磁盘会被物理清理。

【编辑推荐】

【责任编辑:张燕妮 TEL:(010)68476606】

点赞 0

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值