[[326625]]

在云主機(jī)的日常運(yùn)維工作中，我們的工程師經(jīng)常會(huì)遇到用戶上報(bào)的文件丟失類問題，原因多種多樣，這些問題對用戶造成了或大或小的困擾?，F(xiàn)將其中較典型的場景梳理出來，希望能夠幫助大家規(guī)避掉這些風(fēng)險(xiǎn)，防止重復(fù)踩坑。

場景一：云主機(jī)重啟后文件丟失

現(xiàn)象：

用戶上報(bào)：我的云主機(jī)重啟后，上面存放的數(shù)據(jù)怎么沒了，是不是云主機(jī)有問題??？！

分析：

與用戶溝通后確認(rèn)，是用戶存儲在/dev目錄下面的文件不見了。很明顯，用戶數(shù)據(jù)存儲在文件系統(tǒng)類型為tmpfs的/dev目錄，tmpfs文件系統(tǒng)默認(rèn)存儲在內(nèi)存中而非持久化的磁盤，所以重啟主機(jī)后數(shù)據(jù)丟失。

解析：

1、何為tmpfs？

tmpfs是一種基于內(nèi)存的臨時(shí)文件系統(tǒng)，數(shù)據(jù)存儲在ram中，性能非常好。

2、Linux系統(tǒng)有哪些tmpfs？

/dev、/dev/shm、/sys/fs/cgroup、/run/user/0等，tmpfs文件系統(tǒng)默認(rèn)為內(nèi)存總大小的一半。通過df 命令可以看到哪些卷是tmpfs文件系統(tǒng)(Filesystem列顯示為tmpfs)：

建議：

1、tmpfs只用于程序/應(yīng)用的緩存；

2、不建議將數(shù)據(jù)放在tmpfs中(除非可承受數(shù)據(jù)丟失的風(fēng)險(xiǎn))。

場景二：誤執(zhí)行rm命令

現(xiàn)象：

用戶上報(bào)：云主機(jī)重啟后ping不通，或者系統(tǒng)一些服務(wù)啟動(dòng)不了，系統(tǒng)關(guān)鍵文件丟失等等。

分析：

1、通過虛擬化的控制臺看到，OS卡在開機(jī)界面并且報(bào)大量的命令不存在；

2、掛載鏡像進(jìn)入系統(tǒng)后，通過less /root/.bash_history查看用戶的操作記錄，可能看到rm -rf / 、rm -rf 、rm -rf . /*(點(diǎn)號與斜杠之間有空格)、rm -rf ./ 等之類的命令，導(dǎo)致大量的系統(tǒng)目錄及文件被刪除掉；

3、執(zhí)行rpm -Va |grep miss 命令校驗(yàn)丟失的系統(tǒng)文件(對于不是通過rpm包安裝的文件無法校驗(yàn))。

建議：

1、慎重使用rm命令，尤其時(shí)帶上-r 及-f 參數(shù)時(shí); 可以加上-i參數(shù)進(jìn)行刪除確認(rèn)；

2、出現(xiàn)誤操作時(shí)，要第一次時(shí)間停掉磁盤的寫入，再想辦法恢復(fù)，避免被刪除文件的磁盤空間被覆蓋；

3、對于刪除的系統(tǒng)文件，可以從其他正常的系統(tǒng)通過拷貝的方式還原；

4、對于一些系統(tǒng)文件或配置文件，還可以通過yum reinstall 包名/yum update 包名 命令重新安裝/升級安裝來還原。

場景三：文件系統(tǒng)損壞（FIO）

現(xiàn)象：

用戶上報(bào)：在云主機(jī)上運(yùn)行的 MySQL數(shù)據(jù)庫異常。

分析：

1、通過監(jiān)控看到云主機(jī)的IOWAIT比較高，懷疑和IO限制有關(guān)：

2、放開云主機(jī)磁盤限制后，仍然出現(xiàn)異常；MySQL服務(wù)不斷的在crash，并且備機(jī)與主機(jī)的現(xiàn)象一樣，打印如下日志：

3、DBA定位，反饋 MySQL的數(shù)據(jù)文件有問題。

4、在備機(jī)上發(fā)現(xiàn)，mysql 數(shù)據(jù)文件所在卷的文件系統(tǒng)有異常并且異常比較嚴(yán)重，在該卷上創(chuàng)建創(chuàng)建文件也會(huì)失?。?/p>

5、通過history命令分析root用戶操作記錄，發(fā)現(xiàn)用戶使用fio命令對/dev/vdb磁盤(/data卷所在的磁盤)直接進(jìn)行壓測，壓測有隨機(jī)寫、順序?qū)懀皇菍?data目錄：

6、MySQL主節(jié)點(diǎn)也有執(zhí)行相同的 fio 操作，由于fio是繞過文件系統(tǒng)層直接對塊設(shè)備進(jìn)行操作，磁盤的真實(shí)數(shù)據(jù)已經(jīng)被覆蓋，導(dǎo)致文件已經(jīng)嚴(yán)重破壞，MySQL數(shù)據(jù)庫無法解析錯(cuò)誤的數(shù)據(jù)文件，從而crash。

7、2臺MySQL主機(jī)的/data卷數(shù)據(jù)已經(jīng)不可靠，需要重新格式化/data卷，并通過備份節(jié)點(diǎn)進(jìn)行恢復(fù)數(shù)據(jù)。

建議：

1、生產(chǎn)環(huán)境要慎用 fio 工具，應(yīng)該在上線前進(jìn)行壓測；

2、使用 fio 命令時(shí)，—filename 參數(shù)一定不要直接指定塊設(shè)備(如/dev/sda、/dev/vdb等)，而要指定一個(gè)普通文件，可以先touch一個(gè)空文件，再指定這個(gè)文件名。

測試完成后，再刪除該文件即可，不然會(huì)占用 -size 參數(shù)所指定的空間。

場景四：文件系統(tǒng)損壞(DD)

現(xiàn)象：

用戶上報(bào)：云主機(jī)文件訪問異常。

分析：

1、云主機(jī)數(shù)據(jù)卷上的文件無訪問，并且ls也異常，報(bào)【Structure needs cleaning】錯(cuò)誤：

2、通過dmesg及 /var/log/messages日志文件看到有大量xfs文件系統(tǒng)的報(bào)錯(cuò)：

3、通過history命令分析root用戶操作記錄，發(fā)現(xiàn)root用戶有使用dd 命令對 /dev/vdb 磁盤(/data卷所在的磁盤)直接進(jìn)行壓測，對/dev/vdb磁盤寫零：

建議：

1、生產(chǎn)環(huán)境要慎用 dd 工具，應(yīng)該在上線前進(jìn)行壓測；

2、使用 dd 命令時(shí) of 參數(shù)一定不要直接指定塊設(shè)備(如/dev/sda、/dev/vdb等)要指定一個(gè)普通文件。

如下：

場景五：數(shù)據(jù)盤被誤刪除

現(xiàn)象：

用戶上報(bào)：云磁盤被誤刪除。

分析：

1、登錄云門戶查看云磁盤的刪除時(shí)間，由于云資源是延遲一段時(shí)間再刪除的，短時(shí)間內(nèi)還可以找回被刪除的資源：

2、在虛擬化控制臺，確認(rèn)磁盤是否已經(jīng)刪除（State狀態(tài)要為Ready）：

3、如果尚未刪除，可以將云磁盤重新attach到主機(jī)；

4、在云門戶同步云磁盤信息。

建議：

1、云磁盤的刪除操作請謹(jǐn)慎，誤刪后數(shù)據(jù)真得無法恢復(fù)；

2、刪除操作前先確認(rèn)：

A. 在主機(jī)上通過lsof -n、df  -h、lvs/pvs/vgs、lsblk等工具確認(rèn)磁盤是否在使用、是否用于擴(kuò)容的卷；

B. 對于非用于擴(kuò)容的卷，確認(rèn)后，先umount卷、并且清除/etc/fstab中掛載點(diǎn)的信息；

C. 用于擴(kuò)容的卷無法直接刪除，刪除會(huì)導(dǎo)致原卷出現(xiàn)異常；

3、出現(xiàn)誤操作時(shí)，要第一時(shí)間聯(lián)系恢復(fù)，否則磁盤會(huì)被物理清理。