简介这份PDF面向Linux/Unix运维人员与系统管理员聚焦服务器故障排查与应急恢复场景适合具备一定命令行基础、希望提升实战排障能力的中高级读者。内容围绕磁盘挂载异常、系统引导失败、依赖库丢失、文件系统修复与存储空间管理等典型问题展开通过真实案例还原故障现象与处理思路。资源包共1个PDF文件约367KB以图文记录形式呈现便于随时查阅与对照复盘。目前已有92人学习。读者可从中获得RAID分区挂载配置、GRUB引导修复、单用户模式救援、/etc/fstab语法理解以及FreeBSD jail空间占满等问题的处理经验并附有日常巡检与高可用模拟实验的注意事项有助于在线上环境中做到胆大心细、快速定位并恢复服务。1. 从一次 RAID1 数据分区挂载异常说起这份故障笔记为什么值得翻凌晨两点一台刚重装完的 CentOS 5.5 服务器四块硬盘做了两组 RAID1一组跑系统一组存数据。系统装完root 进去一条mount /dev/mapper/ddf1_datap1 /data敲下去挂载成功可ll一看文件全乱了——目录名变成乱码大小对不上MySQL 的数据文件看着像被谁啃过一口。那一刻脑子是空的因为 data 分区里躺着的是生产库。后来才反应过来手动 mount 和写进/etc/fstab让系统按defaults挂载行为并不完全一样文件系统检查、挂载选项、设备映射的时序都可能影响结果。这份《明明白白你的Linux服务器-故障篇》收集的正是这类一线排障记录RAID 挂载异常、库文件丢失导致 root 登不上、GRUB 分区被误删、移硬盘后进 Emergency 模式、jail 虚拟机把/usr写满。它不讲教科书式的文件系统原理讲的是故障现场怎么判断、先敲哪条命令、哪一步不能省。适合已经能独立登服务器、但遇到磁盘和引导问题还会慌的运维和开发也适合把 Linux 常用命令背得滚瓜烂熟、却没在真机上处理过 RAID 和 fstab 的人。2. 挂载、fstab 与 fsckRAID1 数据分区显示异常怎么排2.1 为什么手动 mount 正常、文件却是错的RAID1 做完之后操作系统看到的是/dev/mapper/ddf1_datap1这样的设备映射它背后是阵列卡或软 RAID 拼出来的逻辑卷。手动mount只是把块设备挂到目录上内核按默认参数读超级块和 inode。如果这块分区之前被非正常卸载过或者阵列在重装系统时被重新识别过超级块里的状态标记可能还是“dirty”此时直接挂载读出来的目录项就可能错乱。/etc/fstab里的defaults不是“什么都不做”它等价于rw,suid,dev,exec,auto,nouser,async并且会在启动阶段按顺序做挂载配合fsck的第六列决定是否检查。手动 mount 绕过了启动时的检查流程所以看起来挂上了实际数据视图是坏的。判断依据很简单挂载后ll出现大量异常文件名、df -h容量对不上、dmesg里有 EXT3-fs error 或 journal 相关报错。这时候不要往分区里写任何东西先卸载。2.2 正确挂载与 fstab 写法先卸载异常挂载再对分区做只读检查确认没有硬伤后再写 fstab。# 卸载异常挂载的分区避免继续读写 umount /data # 对设备映射做文件系统检查-n 表示只回答 no先看报告不修复 fsck -n /dev/mapper/ddf1_datap1 # 如果报告显示需要修复再用 -y 自动确认修复 fsck -y /dev/mapper/ddf1_datap1 # 手动挂载验证确认文件列表正常 mount /dev/mapper/ddf1_datap1 /data ll /data确认无误后写进/etc/fstab# 设备映射 挂载点 文件系统 挂载选项 dump fsck顺序 /dev/mapper/ddf1_datap1 /data ext3 defaults 0 0这里第六列写0表示启动时不检查适合数据分区已经稳定、不想每次重启都等 fsck 的场景如果希望启动时自动检查可以写2。defaults里的async意味着写操作异步落盘性能好但异常断电时风险略高数据极重要的库可以改成sync代价是写入变慢。改完 fstab 不要直接 reboot先mount -a验证语法没报错再重启。2.3 库文件丢失导致 root 无法登录的单用户模式处理故障二的现象很典型SSH 连上去报/libexec/ld-elf.so.1: Shared object libintl.so.8 not found, required by bash然后连接关闭。原因是 root 的 shell 是 bash而 bash 依赖的libintl.so.8丢了动态链接器加载 bash 失败登录会话直接断。这时候 SSH 已经进不去只能走单用户模式或控制台。步骤是固定的重启进单用户先fsck -y扫盘再mount -a重新挂载然后把 root 的 shell 临时切到不依赖那个库的sh。# 单用户模式下根分区通常是只读的先重新挂载为读写 mount -o remount,rw / # 扫描并修复文件系统这一步不能省 fsck -y # 按 fstab 重新挂载所有文件系统 mount -a # 把 root 的默认 shell 切换到 sh先恢复登录能力 chsh -s /bin/sh root # 重启 rebootchsh -s改的是/etc/passwd里 root 那一行的最后一个字段。切到sh只是应急登录进去后要尽快把丢失的库补回来或者从同版本系统的/lib或/usr/lib下拷贝libintl.so.8到对应位置再用ldd /bin/bash确认依赖完整最后把 shell 切回 bash。fsck -y放在mount -a之前是因为根分区只读时 fsck 才能安全操作如果先mount -a再 fsck可能因为分区已挂载而拒绝检查。3. GRUB 分区被删与 Emergency 模式引导和 fstab 的坑怎么填3.1 误删 GRUB 分区后的网络引导修复故障三的场景是双系统机器GRUB 所在分区/dev/hdb8被误删Windows 2003 和 CentOS 5.3 都进不去。机器没光驱没软驱U 盘量产成 USB-CDROM 也不被老主板支持最后走的是网络引导。常见做法是用 MaxDOS 这类 PXE 网刻工具把机器设为网络启动从 PXE 服务端拉一个 DOS 环境然后在 DOS 下用diskgen或spfdisk重写 MBR或者直接fdisk /mbr。如果 GRUB 还能进到grub提示符可以手动把引导权转交给 Windows 分区# 在 grub 提示符下执行 rootnoverify (hd0,0) chainloader 1 bootrootnoverify把第一块硬盘的第一个分区设为根设备但不加载文件系统chainloader 1把当前分区首扇区的引导记录加载进来相当于让 GRUB 把控制权交给 Windows 的引导代码。这只适合 GRUB 本身还在、只是菜单或分区表乱了的情况如果 GRUB 所在分区整个没了还是得先重建 MBR 和 GRUB。修复完重启如果又回到 GRUB 报错说明 MBR 写进去了但 GRUB 的 stage 文件没找回来需要进救援模式重装 GRUB。3.2 移走硬盘后进 Emergency 模式的 fstab 处理故障四更常见同事移走一块硬盘直接启动 RHEL5系统进了 Emergency 模式。原因是/etc/fstab里还写着那块已经不存在的硬盘的挂载项启动时 mount 找不到设备超时后掉进紧急模式。很多人第一反应是硬件坏了其实先看 fstab。在 Emergency 模式下输入 root 密码进入根分区此时通常是只读的先 remount 成读写再编辑 fstab 把不存在的设备注释掉。# Emergency 模式下把根分区重新挂载为读写 mount -o remount,rw / # 编辑 fstab把已移除硬盘对应的行用 # 注释 vi /etc/fstab # 确认没有其他挂载错误 mount -a # 重启 rebootmount -o remount,rw /是关键Emergency 模式默认只读不 remount 就没法改文件。改完 fstab 后mount -a验证一遍没有报错再重启。这里有个血泪经验任何硬件变更之前先看/etc/fstab里有没有对应条目有就提前注释或改成noauto别等进了 Emergency 才想起来。3.3 用 find -newer 定位疯狂写盘的文件故障五是 FreeBSD jail 虚拟机里程序死循环不停写某个文件把/usr占满Nagios 狂报警。要快速找出是哪个文件在涨可以用find的-newer参数先建一个时间戳文件再找比它更新的文件。# 建一个当前时间戳的测试文件 touch /tmp/test # 找出根下比 test 更新的文件按修改时间排序 find / -newer /tmp/test -type f -exec ls -lh {} \; 2/dev/null | sort -k5 -h-newer /tmp/test表示修改时间晚于 test 文件的文件2/dev/null把权限不足的报错丢掉sort -k5 -h按文件大小人类可读排序。这样能快速锁定正在被写的那个大文件。找到后不要直接删先lsof看是哪个进程占着确认是死循环进程后再处理。FreeBSD 和 Linux 的find参数基本一致这套方法在两种系统上都能用。4. 避坑与排查五个真实故障里的常见误操作4.1 挂载异常后继续写数据现象ll看到文件名乱码但觉得“还能读”继续往分区里拷文件或启动 MySQL。原因文件系统处于不一致状态目录项和 inode 可能已经错位写入会覆盖真实数据。解决一旦发现挂载后文件异常立即umount先fsck -n看报告再决定是否fsck -y修复修复前不做任何写操作。4.2 fstab 改完不验证直接重启现象改完/etc/fstab直接reboot结果系统起不来又进 Emergency。原因fstab 语法错误、设备名写错、挂载点不存在都会导致启动时 mount 失败。解决改完先mount -a没报错再重启不确定的条目先加noauto需要时手动挂。4.3 单用户模式下先 mount -a 再 fsck现象进单用户后习惯性mount -a再跑fsck结果 fsck 报“文件系统已挂载”拒绝检查。原因fsck 要求文件系统未挂载或只读挂载才能安全操作。解决顺序固定为mount -o remount,rw /→fsck -y→mount -a根分区只读时先 remount 再检查。4.4 删 GRUB 分区后只重写 MBR现象用fdisk /mbr重写 MBR 后重启还是进不了系统。原因MBR 只是第一阶段引导GRUB 的 stage1_5 和 stage2 文件在原来那个分区里分区没了这些文件也没了。解决重写 MBR 后还要进救援模式重装 GRUB或者用grub-install把引导文件装到现有分区。4.5 用 find 找大文件时忽略权限报错现象find / -newer test跑出来一堆Permission denied把真正结果淹没了。原因普通用户对很多目录没读权限报错混在输出里。解决加2/dev/null丢弃错误输出或者用 root 跑找到候选文件后用lsof确认占用进程别直接删。5. 从故障笔记到日常巡检把排障经验变成固定动作这份笔记里五个故障真正值钱的不是每条命令而是它们指向的同一类习惯动硬件之前先看 fstab挂载异常先停写再 fsck改配置先验证再重启引导问题先分清是 MBR 还是 stage 文件。我后来把这些动作固化成了一个巡检清单每次上机先跑一遍比出事之后再翻笔记快得多。# 1. 看 fstab 里有没有 noauto 或已不存在的设备 grep -v ^# /etc/fstab # 2. 看所有已挂载分区的使用率和 inode df -h df -i # 3. 看 dmesg 里有没有磁盘或文件系统报错 dmesg | grep -iE error|fail|ext3|ext4|xfs # 4. 看 RAID 状态软 RAID 用 mdadm硬 RAID 看厂商工具 cat /proc/mdstat # 5. 看最近被修改的大文件排查异常写盘 find /var /tmp /usr -type f -size 100M -mtime -1 -exec ls -lh {} \; 2/dev/nullgrep -v ^# /etc/fstab把注释行去掉只看生效的挂载项df -i看 inode 使用率inode 满了也会导致无法创建文件和磁盘满不是一回事dmesg里的磁盘报错往往比监控报警更早出现/proc/mdstat看软 RAID 的同步状态和降级情况最后一条按大小和修改时间找最近一天内变动的大文件适合排查写盘异常。这套命令不依赖特定发行版CentOS、RHEL、FreeBSD 上都能跑只是 FreeBSD 的df和find参数略有差异-mtime -1和-size 100M是通用的。还有一个习惯每次要动硬盘、改 fstab、重装系统之前先把当前 fstab 和分区表备份出来。cp /etc/fstab /etc/fstab.bak和fdisk -l /root/partition.txt两条命令花不了十秒但真出事的时候能省掉大量回忆和猜测。从那以后我每次上架新机器或者调整存储都强制走一遍这个备份加巡检的流程再没因为 fstab 写错进过 Emergency 模式。希望帮到你。本文还有配套的精品资源点击获取