一次断电引发的血案：深度复盘CentOS 7 LVM分区下fstab丢失的排查与修复全记录

CentOS 7 LVM环境下fstab丢失的深度修复指南

当服务器遭遇意外断电时，文件系统损坏往往是最令人头疼的问题之一。最近处理的一起CentOS 7系统宕机案例，由于断电导致/etc/fstab文件丢失，系统无法正常启动。本文将详细记录整个排查和修复过程，并深入分析背后的技术原理。

1. 故障现象与初步诊断

服务器断电重启后，系统无法正常启动，卡在紧急模式。通过现场工程师提供的启动视频，可以看到以下关键错误信息：

Cannot open access to console, the root account is locked. Give root password for maintenance (or press Control-D to continue):

尝试输入root密码后，系统进入紧急救援模式。此时执行基本命令如fdisk -l都提示"command not found"，初步判断系统关键文件可能丢失或损坏。

注意：在紧急模式下，很多常规命令可能无法使用，因为系统只挂载了最基本的文件系统。

2. 深入分析故障原因

断电导致系统异常关闭，可能引发多种文件系统问题：

• 文件系统不一致：未完成的写入操作导致元数据损坏
• 日志文件丢失：XFS等日志文件系统的日志区域损坏
• 关键配置文件丢失：如/etc/fstab这类启动必需文件

在本案例中，最显著的问题是/etc/fstab文件变成了空文件（fstab.empty）。fstab文件记录了系统启动时需要挂载的所有文件系统，它的丢失会导致系统无法正确挂载根文件系统和其他必要分区。

3. 进入救援模式

由于常规修复方法无效，我们决定使用CentOS 7安装U盘进入救援模式：

1. 从U盘启动，选择"Troubleshooting"
2. 选择"Rescue a CentOS system"
3. 选择"1) Continue"尝试自动挂载原系统分区

当自动挂载失败时，选择"3) Skip to shell"进入手动修复环境。此时我们获得了一个基于ISO引导的临时系统，可以执行各种修复命令。

4. 分区与LVM状态检查

在救援模式下，首先检查磁盘分区情况：

fdisk -l

输出显示磁盘采用GPT分区表，包含以下分区：

/dev/sda1 2048 1026047 1024000 500M EFI System /dev/sda2 1026048 2050047 1024000 500M Linux filesystem /dev/sda3 2050048 41943039 39892992 19G Linux LVM

接着检查LVM状态：

lvscan

输出显示两个逻辑卷处于激活状态：

ACTIVE '/dev/centos/root' [17.51 GiB] inherit ACTIVE '/dev/centos/swap' [1.50 GiB] inherit

5. 文件系统修复过程

5.1 挂载逻辑卷

创建一个临时挂载点并尝试挂载root分区：

mkdir /tmpdisk mount /dev/centos/root /tmpdisk

挂载失败，提示文件系统需要修复。

5.2 执行XFS修复

针对XFS文件系统，使用专用修复工具：

xfs_repair /dev/centos/root

当基础修复无效时，使用强制修复选项：

xfs_repair -L /dev/centos/root

警告：-L选项会强制清零日志，可能导致少量数据丢失，仅在必要时使用

5.3 重新挂载并检查

修复成功后，重新挂载root分区：

mount /dev/centos/root /tmpdisk

进入挂载点检查/etc/fstab文件：

cd /tmpdisk/etc ls -l fstab*

发现存在一个空的fstab文件（fstab.empty），这正是系统无法启动的原因。

6. 重建fstab文件

6.1 确定各分区UUID

使用blkid命令获取各分区的UUID：

blkid

输出示例：

/dev/sda1: UUID="A1B2-C3D4" TYPE="vfat" /dev/sda2: UUID="e1b2c3d4-5678-90ab-cdef-1234567890ab" TYPE="xfs" /dev/mapper/centos-root: UUID="f1e2d3c4-5678-90ab-cdef-1234567890ab" TYPE="xfs" /dev/mapper/centos-swap: UUID="a1b2c3d4-5678-90ab-cdef-1234567890ab" TYPE="swap"

6.2 编辑fstab文件

使用vi编辑器重建fstab文件：

vi /tmpdisk/etc/fstab

添加以下内容（根据实际UUID调整）：

UUID=f1e2d3c4-5678-90ab-cdef-1234567890ab / xfs defaults 0 0 UUID=a1b2c3d4-5678-90ab-cdef-1234567890ab swap swap defaults 0 0 UUID=e1b2c3d4-5678-90ab-cdef-1234567890ab /boot xfs defaults 0 0

6.3 验证boot分区

在修复过程中，发现boot分区(/dev/sda2)最初未被正确识别。通过手动挂载确认：

mount /dev/sda2 /mnt ls /mnt

确认包含grub等启动必需文件后，将其信息加入fstab。

7. 系统重启与验证

完成所有修复后，执行以下步骤：

1. 退出chroot环境
2. 卸载所有挂载点
3. 重启系统

exit umount /tmpdisk reboot

系统应能正常启动至登录界面。登录后验证关键功能：

df -h mount cat /etc/fstab

8. 预防措施与最佳实践

为避免类似问题再次发生，建议采取以下措施：

• 定期备份关键文件：

  • /etc/fstab
  • /etc/passwd, /etc/shadow
  • /etc/group, /etc/gshadow
  • 重要配置文件

• 配置不间断电源(UPS)：

  • 为关键服务器配备UPS
  • 配置自动关机脚本

• 使用文件系统日志功能：

  • XFS默认启用日志
  • 对于ext4，确保启用journaling

• 实施监控告警：

  • 监控磁盘SMART状态
  • 监控文件系统完整性

• 建立系统快照：

  • 使用LVM快照定期备份
  • 考虑系统级备份方案

在实际生产环境中，我们为所有关键服务器配置了每日自动备份关键配置文件的cron任务，并部署了UPS系统配合监控软件，确保在电力故障时能够安全关闭系统。