Linux 灾备演练与应急恢复方法

灾备演练前必须验证/boot、/etc/fstab和/proc挂载状态，检查lvm名、uuid、initramfs驱动，rsync需用–delete-after和–dry-run预演，systemd依赖需双向核查，crypttab须与initramfs一致且路径绝对。

灾备演练前必须验证的 3 个挂载点状态

没验证就拉起灾备环境，90% 的恢复会卡在 /boot、/etc/fstab 和 /proc 挂载异常上。真实场景里，LVM 逻辑卷名变更、UUID 冲突、initramfs 未更新都会让系统停在 emergency mode。

• 用 findmnt -D 看灾备机当前所有挂载是否与生产一致，特别注意 /boot 是否挂了 EFI 分区（/boot/efi）而非普通 ext4
• 检查 /etc/fstab 中所有 UUID 是否匹配 blkid 输出——别信旧文档里的“已同步”，重做镜像后 UUID 必变
• 运行 lsinitrd | grep -E "(lvm|raid|nvme)"，确认 initramfs 包含灾备机实际需要的驱动模块；x86_64 生产机做的镜像直接拉到 ARM64 灾备机上必然失败

rsync 增量同步时绕不开的 –delete-excluded 陷阱

用 rsync 做文件级灾备，--delete 很容易误删灾备机上的关键配置。真正安全的做法是把排除规则和删除逻辑拆开，而不是靠记忆“这次没加 –delete”。

• --delete-after 比 --delete 更可控：先传完再删，避免网络中断导致灾备端清空
• 如果用了 --exclude="/var/log/*"，必须配 --delete-excluded，否则上次同步留下的旧日志不会被清理，磁盘迟早爆掉
• 永远在灾备端用 rsync --dry-run 预演一次，重点看输出里有没有 deleting xxx 出现在你不期望的位置（比如 /etc/nginx/conf.d/ 下）

systemd 服务依赖链断裂导致恢复后服务起不来

灾备机启动后 systemctl status nginx 显示 inactive，但手动 systemctl start nginx 又能跑——大概率是 After= 或 Wants= 指向了生产环境才有的 service（比如 consul-agent.service），而灾备机根本没装。

• 用 systemctl list-dependencies --reverse nginx.service 查谁依赖 nginx，再用 systemctl list-dependencies nginx.service 查它依赖谁，双向扫一遍
• 检查 /usr/lib/systemd/system/*.service 和 /etc/systemd/system/*.service 里所有 After=、Requires=、Wants= 后面的服务名，在灾备机上是否存在（systemctl list-unit-files | grep xxx）
• 别改原 service 文件，用 systemctl edit nginx.service 加 [Unit] ConditionPathExists=/etc/nginx/nginx.conf 这类轻量守卫，比硬删依赖更稳妥

应急恢复时别碰 /etc/crypttab 和 /etc/crypttab.initramfs

加密卷灾备恢复最常翻车的不是密码输错，而是 /etc/crypttab 里写的 mapper name 和 initramfs 里预设的不一致，导致解密成功但设备节点没生成，/dev/mapper/xxx 根本不存在。

• 灾备机首次启动前，用 lsinitrd -f /etc/crypttab 确认 initramfs 里打包的是哪个版本的 crypttab；如果没打进去，dracut -f 重做前必须 cp /etc/crypttab /etc/dracut.conf.d/99-crypttab.conf
• /etc/crypttab 第二列（device path）必须写绝对路径，比如 /dev/disk/by-uuid/xxxx，不能写 /dev/sdb1——设备名在不同机器上完全不可靠
• 如果灾备机用 LUKS2，而生产是 LUKS1，cryptsetup luksDump 输出的 LUKS version 必须一致，否则 initramfs 里的 cryptsetup 工具可能无法识别

灾备不是“同步完就能用”，是“每个挂载点、每条依赖、每个加密配置都得按灾备机的真实硬件和内核重新对齐”。漏掉任意一个，应急时花十分钟排查，远不如演练时多花三十秒验证。