磁盘「挂载掉了，数据别删」——查下来是一行 fstab 写错了盘名

discuz

磁盘「挂载掉了，数据别删」——查下来是一行 fstab 写错了盘名

前几天碰到一台宝塔的 Discuz 服务器，管理员一上来就是一句：磁盘挂载掉了，帮我挂回去，注意有数据别把我数据删了。顺带还补了一句：磁盘也爆了，帮我查查是不是日志占的。

先说结论，省得看着吓人：硬盘没坏，是一行 fstab 写错了盘名。

先说那个"磁盘掉了"。

我上去先把只读信息捞了一遍：lsblk -f、cat /etc/fstab、再翻 journalctl 里 www.mount 的失败记录。三样一对，问题就露出来了——fstab 里写的是

1. /dev/sdb1 /www ext4

复制代码

，可这个 sdb1 其实是块 1M 的 BIOS boot 分区，压根没有文件系统；真正 50G 的那块 ext4 数据盘，是

1. /dev/sda1

复制代码

。

开机按 fstab 去挂，自然报 wrong fs type / bad superblock，挂载失败。于是 /www 这层就成了挂在根分区上的一个空目录——MySQL 的 datadir 在这里、nginx 的配置也在这里，一下全"消失"了：

· MySQL 找不到数据目录，起不来；
· nginx 开机自启时配置全不在，failed；
· php-fpm 没人拉。

连锁下来就是：宝塔面板打不开、站点 502。

这里有个值得记一笔的坑：fstab 里最好写 UUID，别写 /dev/sdX。 /dev/sda、/dev/sdb 这种名字是会变的——加一块盘、换个顺序，名字就换了。写死了设备名，就等于把挂载绑在一次侥幸上。真数据盘的 UUID 用 blkid 一看就有。

数据没丢。改之前我先

1. cp -a

复制代码

备份了 fstab，再把设备名换成 UUID；动手前还先

1. mount -o ro /dev/sda1 /mnt/check

复制代码

只读挂上去，确认数据真在里面，才敢动。改完

1. mount /www

复制代码

+ findmnt + df 回读一遍，确认 rw 挂上、数据目录齐了。

再说那个"磁盘爆了"。

/wwwwlogs 那堆日志加起来 才 8.3M，完全不背这个锅。真占地方的是另外四样：

· MySQL 的 binlog，约 5.8G（配置里写了过期天数，可写入量大，一天能涨 7G）；
· 宝塔的站点备份包，单个 6.1G；
· 手工分卷压缩的旧备份，约 6.3G；
· 一个历史错误日志，1.4G（系统里换过环境，那之后就没再写过）。

凭感觉清日志，最容易清错对象。 先 du / find 把大文件按体积列出来，比猜准得多。

最后补一个小认知点：中途

1. systemctl is-active

复制代码

一直报 active，可 ps 里连 mysqld 的影子都没有。那是 init 脚本的假象——它当时 PATH 缺失、/www 又没挂上，报表自然不准。判断一个服务是不是真活着，得看进程、socket、端口三样，不能只信 is-active。

复盘就两句话：

· 「磁盘挂载掉了」未必是磁盘的事，可能是一行配置的顺序依赖写反了——认盘先只读、改 fstab 先备份；
· 「是不是日志占满了」要用证据回答，别用直觉——大文件是靠 du 找出来的，不是靠猜。

大鹏运维

这个坑我们也踩过，跟这篇一模一样。

教训就是：fstab 里尽量别写 /dev/sdX，用 UUID 或者 LABEL 稳当得多——换机器、插拔硬盘之后设备名太容易变了。我们那次是数据盘没挂上，面板和数据库全起不来，排查半天才反应过来是盘名对不上。