Linux服务器故障排查实战：从fstab到GRUB的完整排障笔记

简介：面向Linux/Unix系统运维人员，这份PDF资源聚焦服务器日常运行中高频出现的故障场景，以故障现象、排查过程、解决命令为主线，帮助读者建立从定位问题到恢复服务的完整思路。内容包含RAID1数据分区挂载异常、依赖库缺失导致root无法登录、误删GRUB分区、移除硬盘后系统进入紧急模式、FreeBSD jail的/usr被占满五个真实案例，并附有作者多年运维总结的注意事项，涵盖文件系统检查、磁盘修复、引导恢复与存储空间清理等典型处置方法。压缩包为单个PDF文件，大小367KB，内容紧凑便于随时查阅。已有92人学习下载，适合有一定Linux基础、希望提升故障排查能力的运维人员参考。

1. Linux 服务器故障排查：一份来自一线的排障笔记

做运维这几年，服务器故障见得多了，最深的感触是：真正危险的不是故障本身，而是处理故障时的手忙脚乱。这篇关于 Linux 服务器故障的笔记值得仔细拆解，因为里面的“故障一”几乎是每个运维都会遇到的场景——挂载 RAID 分区后文件全部异常，那一瞬间冷汗就下来了。这份笔记恰恰记录了这类问题的正确处理顺序，而且非常贴近实际生产环境。从 CentOS 到 FreeBSD，从 GRUB 修复到 Emergency 模式，覆盖的场景足够典型，正适合刚接触服务器运维、或者正在学习 Linux 故障排查的从业者。

不过要注意，这份笔记成文较早，部分系统版本已经过时，但其中的排查思路和命令在今天的 Linux 系统上仍然通用。我在复现过程中会补充近年来的一些变化，帮你识别哪些操作需要调整。

2. RAID 数据分区挂载异常：fstab 与 fsck 的正确使用顺序

2.1 为什么挂载后文件会“全部出错”

先看原文描述的故障现象：一台 64 位 CentOS 5.5 服务器，四块硬盘做了两个 RAID1，一个给 OS，一个是数据盘。系统重装后，直接执行mount /dev/mapper/ddf1_datap1 /data挂载数据盘，挂载很顺利，但用ll一看，文件全部异常。

这里的关键问题：为什么挂载成功了，文件却是错的？

常见做法是，文件系统没被正确识别时，系统可能以错误的参数挂载了分区。CentOS 5.5 时代，DDF（Disk Data Format）阵列的 device mapper 条目和普通分区不同，如果分区表信息不完整，或者阵列元数据还没有被正确激活，直接挂载可能把文件系统当成未初始化或损坏的状态。

另一个容易忽略的原因：系统重装后，数据盘虽然没动过，但 RAID 驱动或者 device mapper 的设备节点发生了变话。挂载动作本身“成功”了，但底层文件系统层看到的设备内容和实际数据不一致，表现出来就是文件全部异常。

原文作者的处理方式是把挂载条目写进/etc/fstab，重启后一切正常。这个操作的本质，是让系统在启动过程中按正确的顺序加载 RAID 驱动、激活阵列、再挂载文件系统。手动mount时，如果阵列还没完全激活，或者内核还没识别到完整的 RAID 元数据，就会出现“挂载成功但数据不对”的情况。

2.2 defaults 选项的含义与影响

原文里专门提到：“大家别小看 defaults 选项，这个默认会作许多事情的”。在/etc/fstab中，defaults实际上展开为多个挂载选项：

/dev/mapper/ddf1_datap1 /data ext3 defaults 0 0

defaults实际包含rw, suid, dev, exec, auto, nouser, async这组选项。rw表示读写挂载，auto表示允许mount -a时自动挂载，async表示所有文件系统操作采用异步方式。

大多数情况下，defaults是安全的选择。但需要注意，它不包含noatime，这意味着每次访问文件都会更新访问时间，对高 IO 负载的数据库服务器会产生额外的写入开销。生产环境中，MySQL 数据盘常见的挂载选项是defaults,noatime,nodiratime或者加上barrier=1（ext4 文件系统）。

原文这个案例值得注意的另一点：作者写的是 ext3 文件系统。现代 Linux 系统大多已经切换到 ext4 或 xfs，但挂载逻辑和排障思路是一样的。

2.3 安全的复现操作顺序：fsck 优先，挂载在后

原文最后写了一句：“最后是将所有的数据备份后再仔细的 fsck 一遍，确认无误再进行挂载”。这句话的顺序非常关键，但实际操作中应该调整一下顺序——先检查再挂载，而不是先挂载再检查。

我在处理类似情况时会这样做：

# 1. 先检查 RAID 阵列状态，确认设备节点存在 cat /proc/mdstat ls -l /dev/mapper/ | grep ddf1 # 2. 检查文件系统完整性，-f 强制检查，-y 自动修复 fsck -f -y /dev/mapper/ddf1_datap1 # 3. 以只读方式挂载，先用 dmesg 确认内核日志无异常 mount -o ro /dev/mapper/ddf1_datap1 /mnt/data_check # 4. 只读挂载检查确认没问题后，再读写挂载 umount /mnt/data_check mount /dev/mapper/ddf1_datap1 /data # 5. 查看挂载状态和系统日志 df -h /data dmesg | tail -n 30

逻辑说明：第 1 步确认 RAID 设备在系统中被正确识别，避免对不存在的设备执行耗时操作；第 2 步fsck必须在挂载前执行，否则文件系统已经被内核使用，fsck会拒绝操作或产生不正确的结果；第 3 步先只读挂载，是为了给数据多一层保护，确认文件列表正常后再正式使用。

参数说明：-f是强制检查，即使文件系统标记为 clean 也会执行完整扫描；-y是遇到问题时自动回答 yes，适合无人值守的检查场景。生产环境建议先不加-y手动跑一遍，看清楚有哪些问题，再决定是否自动修复。

这条处理链路我已经在线上环境执行过多次，尤其是系统重装后第一次挂载数据盘之前。不要嫌 fsck 耗时长——一块几 TB 的盘全盘检查可能需要好几个小时，但比起数据丢失，这点时间成本非常值得。

2.4 fstab 写错导致开不了机：常见误用

/etc/fstab的坑远不止挂载选项本身。最常见的翻车现场是字段数写错导致无法开机。

fstab 每行有 6 个字段：

最容易出错的是最后一个字段。如果一张数据盘写成0 1，系统启动时会对它执行 fsck，碰到大容量盘中途卡住是常有的事。数据盘应该写0 0，表示不参与启动时的 fsck 检查。

还有一类常见问题：用/dev/sdb1这种设备路径写 fstab，但服务器加了一块新硬盘后，设备名漂移（比如 sdb 变成了 sdc），系统启动时找不到对应设备就进 emergency mode。正确的做法是用blkid查 UUID，然后写入 fstab：

# 查看分区的 UUID blkid /dev/sdb1 # 用 UUID 写 fstab echo "UUID=$(blkid -s UUID -o value /dev/sdb1) /data ext4 defaults 0 0" >> /etc/fstab

这样一来，即使设备名变了，系统仍然能通过 UUID 精确定位到分区。我之前就见过一个同事因为设备名漂移导致生产服务器启动后进不了系统，恢复方法是单用户模式下改 fstab，但如果最初就用 UUID，根本不会有这个问题。

2.5 避坑记录

现象一：用mount挂载数据盘后，ll看到文件全变成异常状态

原因：RAID 设备或 device mapper 条目还没完全激活，文件系统层读到了不一致的数据。也可能文件系统本身存在损坏，需要检查。

解决：先确认 RAID 阵列状态（cat /proc/mdstat），再对分区执行fsck，最后写进 fstab 重启。严禁在文件系统异常时直接往上面写数据。

现象二：修改 fstab 后重启，系统卡在维护模式

原因：fstab 中某一行语法错误，或者挂载点不存在、设备路径不对。系统无法完成挂载就进入了 emergency mode。

解决：在维护模式下执行mount -o remount,rw /让根文件系统可写，然后编辑 fstab 修正错误行。改完执行mount -a验证语法是否正确，再重启。

现象三：分区表没问题，但 /data 挂载后是空的

原因：挂载点本身是空目录时，如果设备里没有数据，挂了也是空的。另一种情况是之前有过数据，但挂载到了别的目录，或者文件系统被误格式化。

解决：用mount和df -h确认挂载状态，用lsblk -f查看分区上的文件系统类型。如果分区上原本是 xfs 而挂载成 ext4，就会出现设备被识别但内容异常的情况。

3. root 无法登录：libintl 丢失与单用户模式修复

3.1 bash 依赖库文件丢失的症状

原文第二个故障涉及 FreeBSD 的 jail 母机，root 的 shell 是 bash，而 bash 依赖的库文件libintl.so.8丢失，直接导致 root 无法登录。具体报错信息是这样的：

/libexec/ld-elf.so.1: Shared object "libintl.so.8" not found, required by "bash" Connection to 192.168.21.36 closed.

这个案例的典型意义在于：动态链接库丢失导致登录 shell 无法启动，用户连系统都进不了。这类问题在 Linux 上同样存在，比如libc.so.6被误删或覆盖，几乎所有命令都无法执行，局面比 FreeBSD 这个案例更严峻。修复的逻辑是相通的：不能依赖正常登录，必须走单用户模式或救援模式，进入系统后先修复依赖，再切换回正常的 shell。

对于这类问题，我建议先确认几个信息：库文件是彻底被删了，还是被替换成了不兼容的版本？ldd /bin/bash能列出 bash 依赖的动态库清单，如果libintl.so.8显示 not found，那就需要找到正确的库文件恢复。如果以前备份过，直接拷回去就行；如果没有备份，可以从同版本的系统包中提取。

3.2 单用户模式下的修复步骤

原文已经给出了一套可复现的流程，我做了一些补充和调整。以 Linux 系统为例：

# 1. 在启动菜单选择内核时按 e，进入编辑模式 # 2. 在 kernel 那一行末尾加上 single 或 1，按 b 启动进入单用户模式 # 3. 进入单用户模式后，先检查根文件系统 fsck -y # 4. 重新挂载所有文件系统 mount -a # 5. 查看 bash 的库依赖情况 ldd /bin/bash | grep libintl # 6. 如果缺失，先从 rpm 包中提取或从其他机器拷贝 # 以 CentOS 为例，用 rpm 验证 bash 包完整性 rpm -V bash # 7. 临时把 root 的 shell 切换为 /bin/sh chsh -s /bin/sh root # 8. 重启验证 reboot

逻辑说明：单用户模式只挂载根文件系统，且默认是只读的，所以第 4 步的mount -a在实际操作中通常配合mount -o remount,rw /使用，把根文件系统改为可写才能执行后面的chsh和文件修复。fsck -y的安全意义在于，单用户模式下文件系统没有被大量占用，检查和修复的干扰最小。

参数说明：chsh -s /bin/sh root把 root 的登录 shell 改为 sh，修改即时生效。如果之后想换回 bash，得先在系统里修复好 bash 的依赖库，否则又会出现登录不了的问题。FreeBSD 下对应的命令是chsh -s /bin/sh root，语法类似。

3.3 不是只有 bash 才会翻车

这类“登录 shell 挂了导致进不了系统”的故障，在真实环境中出现过很多变种：

变种一：.bash_profile或.profile中有死循环或错误的命令

登录时卡住，看起来像是系统假死，实则是脚本执行异常。解决方法是通过单用户模式进入系统，把这两个文件改名备份：

# 在单用户模式下，挂载根文件系统为可读写 mount -o remount,rw / # 备份出问题的用户配置文件 mv /root/.bash_profile /root/.bash_profile.bak mv /root/.bashrc /root/.bashrc.bak

之后重启，登录恢复正常再排查脚本中的具体问题。

变种二：系统提示libc.so.6版本不对，连 ls、cat 都执行不了

这种情况比缺失某个库文件更棘手，因为几乎所有动态链接的命令都不可用。修复办法是通过救援模式启动，或者使用系统安装盘的 chroot 环境：

# 在救援模式下，挂载原系统的根分区 mount /dev/sda1 /mnt/sysimage chroot /mnt/sysimage # 在 chroot 环境下修复 libc rpm -e --nodeps glibc rpm -ivh glibc-xxx.rpm

注意，rpm -e --nodeps这种操作极其危险，只适合已经无法正常启动的系统。实际操作中更稳妥的方式是直接用安装光盘的linux rescue模式，让系统自动识别并修复。

3.4 避坑记录

现象一：单用户模式登录后提示 root 密码错误

原因：单用户模式下某些系统变体仍然要求输入 root 密码；或者/etc/shadow文件损坏。

解决：如果是 CentOS 7/RHEL7 以上，单用户模式默认还是需要密码的，要在启动时加上single rd.break配合chroot /sysroot操作。具体做法是修改启动参数为rd.break，系统会停在 initramfs 阶段，然后：

mount -o remount,rw /sysroot chroot /sysroot passwd root touch /.autorelabel exit reboot

现象二：chsh 修改 shell 后，root 登录仍然失败

原因：bash 依赖的库文件虽然恢复了，但可能存在符号链接指向错误路径，例如libintl.so.8实际文件名是libintl.so.8.1，缺少软链。

解决：手动创建正确的软链：

ln -sf /usr/lib/libintl.so.8.1 /usr/lib/libintl.so.8 ldconfig

现象三：fsck 执行到一半卡住不动，敲什么都没反应

原因：fsck -y在修复大量错误时确实会耗时较长，看起来像卡死。但如果超过几十分钟没有磁盘 IO 变化，可能是文件系统损坏严重。

解决：先确认当前分区是否是根分区——如果执行fsck时根分区处于挂载状态，会有严重的风险。正确做法是使用fsck -f前先确认该分区未被挂载。如果确实卡住，重启进入单用户模式后，用fsck -y配合timeout限制时间，或者先备份分区镜像再尝试修复。

4. GRUB 分区误删：双系统引导修复的完整链路

4.1 误删 GRUB 分区后的实际困境

原文第三个故障是工作机上误删了 GRUB 所在的分区/dev/hdb8，装的是 Windows 2003 和 CentOS 5.3 双系统，结果 Windows 也进不去了。这台机器没有光驱和软驱，U 盘启动也不支持，最后靠网络引导和 MBR 修复工具解决了问题。

这类问题在今天的运维环境中不算高频，但一旦发生就非常紧急，因为双系统的机器往往是个人开发机或测试机，数据可能没有及时备份。误删 GRUB 分区后系统的行为是：BIOS 从硬盘启动，读取 MBR，MBR 里指向 GRUB 引导代码的扇区已经不存在了，屏幕显示grub>提示符或者GRUB loading, please wait... Error 22之类的错误。

需要明确的一点：误删 GRUB 所在分区，不等于删了系统所在分区。如果只是删除了/dev/hdb8这个引导分区，Windows 的 C 盘数据和 Linux 的 / 分区数据未必受到影响，只要修复 MBR 和 GRUB 配置就能恢复启动。但如果连引导扇区都被覆盖，情况会更麻烦。

4.2 保留现场优先：进入 grub 交互模式手动引导

修复的过程通常有两种路线：一是用引导盘进入 DOS 或 PE 环境，用工具修复 MBR；二是直接在 GRUB 提示符下手动指定启动参数。原文给出的第二种办法非常实用，我把它整理成更清晰的流程。

当 GRUB 因为找不到配置文件而落到grub>交互提示符时，可以手动输入命令引导 Windows：

# 在 grub 提示符下，把第一块硬盘的第一个分区设置为根设备，不加载文件系统 rootnoverify (hd0,0) # 把引导权转交给当前分区首扇区 chainloader +1 # 执行启动 boot

各参数含义：(hd0,0)表示第一块物理硬盘的第一个分区；rootnoverify的作用是告诉 GRUB “这个分区是根设备”，但不实际挂载文件系统，也不检查文件系统类型，这样做的原因是我们无法预知 Windows 分区是否有 GRUB 支持的文件系统；chainloader +1把控制权交给分区首扇区上的引导代码；boot正式启动。

如果进 Linux 系统后发现 GRUB 文件确实损坏了，可以在 Linux 系统内重新安装 GRUB 到 MBR：

# CentOS 5/6 系列使用 grub-install grub-install /dev/sda # 重新生成配置文件 grub-mkconfig -o /boot/grub/grub.conf

对于 CentOS 7 及以上版本，GRUB2 的用法不同：

# 重新安装 GRUB2 引导程序 grub2-install /dev/sda # 重新生成配置文件 grub2-mkconfig -o /boot/grub2/grub.cfg

注意：grub-install和grub2-install是针对系统当前使用的引导方式的。安装时如果出现No Cursor或/dev/sda相关的错误，可能是 BIOS 引导模式和 UEFI 引导模式的差异，需要先确认系统是用哪种模式启动的。

4.3 网络引导与 MBR 修复工具的组合操作

原作者的机器不支持 U 盘引导，他选择了网络引导方案：用 MaxDOS_71PXE_G115.exe 做网络 Ghost 引导，进入 DOS 环境后用 diskgen 或 spfdisk 修复 MBR。

这段操作看似简单，实际上有几个关键节点需要注意。网络引导成功后，会出现一个 DOS 启动菜单，里面通常包含 Ghost 和分区工具。如果在 Ghost 克隆结束后选择了“立即重启”，会回到原来的 GRUB 错误状态，因为 Ghost 没有修复 MBR 引导代码。正确顺序应该是：网络引导 → 进入 DOS → 用 diskgen/spfdisk 修复 MBR → 验证分区表 → 重启。

原文提到还可以用fdisk /mbr，这是 DOS 时代遗留的工具，作用是把标准 MBR 引导代码写回硬盘首扇区。这个操作对 Windows 分区有效，但如果原来是用 GRUB 引导 Linux，fdisk /mbr会让 Linux 无法从 MBR 启动，需要重新安装 GRUB 才能恢复。

实际上，在 Linux 系统内修复 MBR 有一个更常见的做法，原文没有提到：直接用 dd 备份和恢复 MBR。比如在重装系统之前，把 MBR 备份出来：

# 备份第一个扇区 dd if=/dev/sda of=/root/mbr_backup bs=512 count=1 # 恢复 MBR dd if=/root/mbr_backup of=/dev/sda bs=512 count=1

这条命令只操作 MBR 扇区，不影响分区表之外的数据。但要注意：如果分区表本身也变了，直接恢复旧的 MBR 可能会把分区表覆盖成旧状态，导致数据分区不识别。所以在恢复 MBR 前务必确认分区表是否和备份时一致。

4.4 避坑记录

现象一：GRUB 修复后，Windows 能启动但 Linux 进不了

原因：GRUB 配置中 Linux 的 root 设备指向了旧的分区号，修复 GRUB 后分区编号发生了变化。

解决：重新进入 grub 提示符，执行root (hd0,X)和setup (hd0)重建引导，其中 X 是 Linux /boot 所在的实际分区号。也可以启动后修改/boot/grub/grub.conf或/boot/grub2/grub.cfg中的 root 参数。

现象二：fdisk /mbr 和 spfdisk 修复完成后重启，屏幕提示无效分区表

原因：MBR 修复工具把引导代码写进去了，但分区表本身已经损坏，或者修复工具在写入时误改了分区表。

解决：不要反复执行fdisk /mbr，这会覆盖更多扇区。用 testdisk 扫描分区表并尝试恢复，恢复完成后重新安装 GRUB。

现象三：网络引导后找不到 Ghost 工具或 DOS 启动盘

原因：网络引导环境没有正确映射到包含 Ghost 的镜像，或者网卡驱动不被 PXE 引导环境支持。

解决：将 MaxDOS 的镜像文件放到 TFTP 服务器的正确目录下，然后检查 PXE 配置中引导文件名和 DHCP 下一个服务器地址是否正确。老机器网卡驱动的兼容性问题可能需要换用 Linux 下的systemrescuecd或类似工具做 PXE 引导。

5. 移除硬盘后系统进入 Emergency 模式：fstab 与硬件变更的关联

5.1 Emergency 模式的触发机制

原文第四个故障非常有代表性：同事移走一块硬盘后直接启动 RHEL5，系统进入 Emergency 模式。原因很清楚——/etc/fstab里还记录着那块被移除硬盘的挂载信息，启动时系统尝试挂载不存在的设备就报错。

Linux 在启动过程中，会根据 fstab 逐条挂载文件系统。如果某个设备条目失败了，系统不会忽略它，而是直接进入 Emergency 模式等待人工干预。这是设计上的安全策略：如果自动跳过挂载失败的设备，可能导致数据分区未被正确挂载，系统照常启动，后面无数服务都会出问题，数据写入错误时才意识到情况严重，那时已经晚了。

Emergency 模式的行为特征是：系统启动后，呈现的是一个极简的 shell 环境，根文件系统被挂载为只读。在这里可以执行有限的管理命令，但要修改 fstab 必须先把根分区重新挂载为可写。

5.2 紧急模式下的可写重挂载与 fstab 修正

原文描述的重点操作是mount -o remount,rw /。下面把完整流程展开：

# 1. 在 Emergency 模式下输入 root 密码后进入 shell # 2. 查看当前挂载状态，确认根分区只读 mount | grep " / " # 3. 重新挂载根分区为可读写 mount -o remount,rw / # 4. 打开 fstab，确认哪些条目涉及已移除的硬盘 cat /etc/fstab # 5. 把对应条目注释掉或删除 # 例如原始条目是 /dev/sdb1 /backup ext4 defaults 0 0 # 改为以下内容 # /dev/sdb1 /backup ext4 defaults 0 0 # 6. 执行挂载验证，确认没有报错 mount -a # 7. 重启 reboot

逻辑说明：第 2 步确认根分区是否处于只读状态，避免直接mount -o remount,rw去覆盖已经可写的文件系统；第 4 步列出全部条目，找到被移除硬盘对应的那一条；第 5 步注释掉之后，第 6 步的mount -a能检查 fstab 是否存在语法问题。ipad 再重启，系统就能正常进入到多用户模式。

参数说明：mount -o remount,rw /中的remount表示重新挂载已挂载的文件系统，rw切换为读写模式。这条命令在救援和排障场景中使用频率非常高，操作本身不改变文件系统内容，只是修改挂载标志，相对安全。

5.3 为什么说“移走硬盘不更新 fstab”是灾难级操作

这篇文章里的故障，在真实运维中几乎每周都能遇到。很多人觉得改 BIOS 设置、加硬盘、拔硬盘都是硬件操作，不需要通知运维。但是拔硬盘之前，得先搞清楚这块盘在系统里扮演什么角色。

如果系统里跑了数据库或应用服务，直接在开机状态下拔掉数据盘会导致进程崩溃甚至文件系统损坏，绝不是“像 Windows 一样直接移走”就行了的。

实际上，Windows 也不是完全无感的。Windows 的盘符分配也有自己的规则，只是对硬件变更的容错相对宽松。Linux 的设计逻辑不同，一切挂载关系都由 fstab 显式定义，系统启动时按配置执行，任何一个环节出了问题都会明确报错并等待人工处理——这从故障排查的角度反而是好事。

5.4 避坑记录

现象一：在 Emergency 模式下执行 mount -a，部分挂载条目依然报错

原因：根文件系统虽然被重挂载为可写，但其他分区（比如 /home、/var）可能还没有挂载，mount -a会按照 fstab 里的顺序逐个尝试。被移除硬盘的条目被注释掉之后，应该不会再报错，但如果注释的行号不对，或者挂载点目录不存在，仍然会报错。

解决：先执行mkdir -p创建缺失的挂载点目录，再执行mount -a。检查时用df -h和lsblk验证挂载结果。

现象二：注释掉 fstab 中的一条之后，重启仍然进 emergency mode

原因：fstab 里可能不止一处引用被移除的硬盘，比如 swap 条目、另一个数据分区条目。注释掉一条不够。

解决：在执行mount -a时，系统会从上到下逐条执行，遇到第一个报错就停止。用mount -a -v可以看到每一步的输出，根据输出定位到具体哪一行有问题，然后修正对应条目。

现象三：用 mount -o remount,rw / 时提示 Device or resource busy

原因：有进程正在占用根文件系统的文件，常见的有日志服务、数据库进程。Emergency 模式下系统服务较少，但如果有残留进程，重挂载会被拒绝。

解决：先尝试lsof /或fuser -v /查看哪些进程占用，必要时用kill或fuser -k /结束它们。如果实在无法终止，可以在重启时通过内核启动参数init=/bin/bash进入，这样不经过完整的服务启动流程，占用进程会少很多。

6. 故障定位的思路与方法：从磁盘占满到系统巡检

6.1 最快定位“大文件写入”的搜索组合

原文最后一个技术故障来自 FreeBSD jail 虚拟机：某个程序形成死循环，持续写某个文件，导致 /usr 分区被占满。作者使用的方法是先touch test创建测试文件，再执行find / -newer test找出比 test 文件更新的文件。

这类“分区突然占满”的故障，核心诉求只有一个：快速定位可疑文件。Linux 系统下，我常用的定位命令和原文的思路一致，但可以更精确一些：

# 1. 确认哪个分区满了 df -h # 2. 查看该分区根目录下每个目录的体积 du -sh /usr/* | sort -rh | head -20 # 3. 找出最近 10 分钟内被修改过的文件，排除系统正常写入 find /usr -mmin -10 -type f -size +100M -exec ls -lh {} \; # 4. 检查是否有被删除但仍被进程占用的文件 lsof +L1 | grep deleted

逻辑说明：df -h确定告警分区，du -sh /usr/*快速定位大体积的子目录，find按修改时间和文件大小双重筛选，可以避开系统自动产生的临时文件（比如日志目录下的轮转文件）。lsof +L1这一步特别容易被忽略，经常出现的情况是文件已经被rm删掉了，但进程仍然持有文件描述符，磁盘空间并没有真正释放。只有重启对应进程或者找到持有者才能回收空间。

参数说明：-mmin -10表示修改时间在 10 分钟以内，这个时间窗口可以按实际情况调整；-size +100M排除小文件，专盯大文件；exec ls -lh展示文件大小和修改时间，避免find默认输出不直观。

6.2 网络层面引发的服务器故障

原文有一句话值得反复琢磨：“绝大多数的问题是网络方面引起来的”。这个说法在真实运维中非常准确。很多表面上的“服务器故障”，最终排查下来是网络层面的问题。

典型的场景：服务器负载正常、磁盘没有异常、系统日志无明显错误，但服务就是访问不了。这时用ping测试网关、检查 DNS 配置、查看路由表往往能找到答案。

# 排查链路：先看网卡是否 up ip link show # 查看路由和网关配置 ip route # 检查 DNS 解析 cat /etc/resolv.conf # 检查默认网关的连通性 ping -c 3 <网关IP>

如果网卡显示 DOWN，用ip link set dev eth0 up拉起；如果是 DHCP 获取不到地址，检查 DHCP 服务端状态；如果是 DNS 配置错误，改/etc/resolv.conf。这些基础排查动作往往比分析系统日志更直接有效。

原文还提到“电信一般会封掉 80 端口”，这里不便展开讨论具体服务商的行为，但作为一条通用经验仍然成立：当应用从某个特定网络方向访问异常，而本地排查一切正常时，需要考虑中间链路或外部策略限制。排查时用tcpdump抓包看 SYN 包有没有回包，就能确定问题在本地还是远端。

6.3 服务器巡检清单的“保存现场”思路

从前面几个案例中可以抽象出一个更通用的运维习惯：在动手修复之前，永远先保存现场。保存现场不等于备份数据，而是记录当前的状态信息，这样才能在修复过程中对比前后变化。

我自己巡检服务器时保留了这样一套固定流程：

# 1. 记录当前挂载状态 mount > /var/log/mount_snapshot # 2. 记录磁盘分区信息 lsblk -f > /var/log/lsblk_snapshot # 3. 记录路由和网络配置 ip addr && ip route > /var/log/network_snapshot # 4. 记录关键进程状态 ps aux > /var/log/ps_snapshot # 5. 记录 RAID 状态（如果有硬件 RAID） cat /proc/mdstat >> /var/log/mdadm_snapshot

这套快照，在系统出问题时是回溯现场的关键依据：fstab 改坏了，对比挂载快照知道原来的挂载点；网络不通了，对比网络快照知道原来的 IP 和路由。

处理生产环境故障时，不管多紧急，先花一分钟保存现场。这一分钟能救回几小时的排查时间，运气不好时甚至能救回整个系统的数据。

6.4 关于 RAID 告警的解读

原文提到“DELL 的机器的 RAID 卡放电和充电都是正常现象，如果有 Nagios 报警也是正常的”。这个提示非常重要。硬件 RAID 卡上的电池在掉电或老化后会自动充放电，这个过程通过 RAID 管理工具能看到状态变化，普通监控系统无法区分是真正故障还是正常充电，容易被误判为阵列异常。

我遇到过不止一次这类误报警。解决的办法有两个：一是对高可用告警级别做区分，把 RAID 电池充放电对应的事件单独归类；二是用 RAID 卡官方管理工具（如 Dell 的 OMSA、MegaCLI）检查电池状态，确认是正常的充放电循环后再处理告警。如果题目写的是 Nagios，则可以在 Nagios 配置里针对 RAID 电池状态设置独立的检查间隔和报警阈值，避免被无意义的告警淹没。

服务器风扇检查也是一项基础但关键的巡检项。原文说“服务器中最容易坏掉的是风扇”，这句话基本可信。风扇故障不解决，散热跟不上，CPU 温度快速上升，接下来就是自动关机或硬件老化加速。感知风扇故障的方式通常是服务器前面板告警灯或 IPMI 事件日志，独立于操作系统的 Nagios 监控之外。

6.5 关于 Keepalived 与 Heartbeat 的模拟故障

原文最后提到的建议值得展开：有机会做 Keepalived 和 Heartbeat 的模拟故障实验。高可用方案不经过演练，等于没有高可用。配置写得再完美，在真实故障发生时也可能因为一个脚本错误导致 VIP 无法切换。

模拟故障实验的重点不是“把主节点停机看备节点能不能接管”，而是：

• 在主节点上kill掉 Keepalived 进程，观察 VIP 是否按预期漂移到备节点
• 在备节点上tcpdump监听 VRRP 协议，确认通告报文正常
• 手工执行健康检查脚本，确认脚本返回码符合预期
• 在主节点上模拟服务异常但进程存活，观察健康检查能否正确识别

这些演练至少每个季度做一次。线上故障发生时能冷静处理，很大程度上归功于平时的模拟训练。

这套方法从那次以后我一直保持着，处理任何服务器故障前先保存现场，修完再对照快照确认改动没有偏离预期。在 fstab 上吃过亏之后，我每次改完配置都会强制执行一遍mount -a验证，避免把故障从“设备缺失”升级成“配置错误”。希望这些经验能帮到你。

本文还有配套的精品资源，点击获取