灾备演练前必须验证/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 工具可能无法识别
灾备不是“同步完就能用”，是“每个挂载点、每条依赖、每个加密配置都得按灾备机的真实硬件和内核重新对齐”。漏掉任意一个，应急时花十分钟排查，远不如演练时多花三十秒验证。
