1. 误删 /usr 到底意味着什么先把结论摆在最前面在 CentOS 这类以 RPM 体系为核心的发行版里/usr不是用户目录而是整个系统绝大多数可执行文件、库文件、共享资源、文档的存放地。/bin、/sbin、/lib、/lib64在现代 CentOS 上基本都是指向/usr下对应目录的软链接。也就是说rm -rf /usr这一条命令下去你删掉的不只是某个文件夹而是把系统的手脚和内脏一起摘了。我见过太多人第一次遇到这个场景时的反应敲完回车终端开始疯狂刷屏报错ls找不到、cp找不到、连rm自己都找不到了然后 SSH 一断彻底进不去。这时候最忌讳的就是慌因为慌乱之下最容易做出第二个错误决定——比如直接重启或者随手reboot把内存里还残存的进程状态也一起丢掉。这篇文章要解决的核心问题就一个在 CentOS 系统/usr目录被误删、系统已经无法正常执行命令的情况下如何通过制作系统 U 盘进入救援环境把系统恢复到可用状态。适合谁看适合所有在物理机、虚拟机、云主机上折腾过 Linux、手上有 root 权限、但还没真正经历过删库级别事故的运维和开发同学。哪怕你现在没遇到把流程走一遍、把 U 盘备好也比出事那天现查资料强得多。需要提前说清楚一个前提/usr被删之后能否 100% 恢复取决于你之前有没有备份、有没有做 LVM 快照、文件系统是什么类型。这篇文章给的是最大概率救回来的通用路径不是万能药。下面我会把每一步的为什么这么做讲透而不是只丢几条命令让你抄。2. 事故现场的第一反应与止损逻辑2.1 为什么第一步是别乱动而不是赶紧修很多人下意识觉得删了东西就赶紧补回来。但在/usr被删的场景下系统里几乎所有命令都依赖/usr/bin和/usr/lib64你敲的每一条修复命令本身可能都跑不起来。这时候继续在故障系统里瞎操作只会让情况更糟。正确的第一反应是冻结现场如果还连着 SSH先别断开但也别执行任何写操作尤其别reboot、别shutdown。如果已经断连直接去物理机/虚拟化控制台准备从外部介质引导。记录下你删之前做过什么、系统版本、分区结构如果还能从别的地方查到。提示/usr被删后很多进程仍在内存中运行比如已经启动的数据库、Web 服务。它们暂时还能响应但一旦重启就全没了。所以不重启是保住最后一点现场信息的关键。2.2 判断损失范围只是 /usr 还是连带其他在动手恢复前得先搞清楚到底删了多少。常见的几种情况删除范围典型表现恢复难度仅/usr部分子目录部分命令可用系统半瘫较低可针对性补文件整个/usr绝大多数命令失效SSH 新连接失败中高需救援环境/usr/lib64软链接目标动态链接器都可能受影响高基本靠重装或备份连带/etc、/var配置和日志全丢极高优先考虑重装判断方法如果还能进单用户或者救援模式用ls -l /看/bin、/sbin、/lib、/lib64这几个软链接是否还在、指向哪里。如果软链接本身也被删了那恢复时要连软链接一起重建。2.3 备份优先于修复这是我最想强调的一条经验在开始任何恢复动作之前如果数据盘和系统盘是分开的先把数据盘挂到别的机器上备份出来。系统可以重装业务数据丢了才是真的灾难。如果系统盘上有重要数据又没单独分区那在救援环境里第一件事也是想办法把能读的数据先dd或者rsync出来再谈修复。我踩过的坑就是一心想着修系统结果修复过程中一次误操作把残留数据也覆盖了得不偿失。3. 制作 CentOS 系统 U 盘从选镜像到写入3.1 镜像选择DVD、Everything 还是 Minimal制作救援 U 盘镜像选择直接决定你进救援环境后手上有多少工具。CentOS 官方提供的镜像大致分几类Minimal ISO体积最小几百 MB但救援模式下可用工具很少很多修复命令要联网装而故障机往往没网。DVD ISO几个 GB包含 Base 和大部分常用包救援模式下的工具比较全是首选。Everything ISO体积最大包最全适合离线环境但下载和写入都慢。我的建议是做救援盘就用 DVD ISO。它自带的rescue模式里能直接用的工具足够应付/usr恢复的大部分场景而且不需要联网。3.2 写入工具与操作要点写 U 盘这件事Windows、Linux、macOS 上各有各的做法但核心原则一样必须用镜像写入模式不能简单复制文件。直接把 ISO 拖进 U 盘是没用的因为引导扇区不会被写入。Linux 下最稳的是dd# 先确认 U 盘设备名千万别写错写错就是删自己硬盘 lsblk # 假设 U 盘是 /dev/sdbISO 是 CentOS-DVD.iso sudo dd ifCentOS-DVD.iso of/dev/sdb bs4M statusprogress oflagsync几个关键点of后面是整块设备/dev/sdb不是分区/dev/sdb1。bs4M是块大小兼顾速度和稳定性太小慢、太大某些 U 盘会出错。oflagsync保证数据真正落盘再返回避免拔盘时还没写完。写完执行sync再拔。Windows 下可以用 Rufus 这类工具模式选DD 镜像模式而不是 ISO 模式否则可能引导失败。macOS 下可以用dd但设备名是/dev/rdiskX用rdisk比disk快很多。注意写盘前一定用lsblk或磁盘管理工具反复确认目标设备。我见过把系统盘当 U 盘写了的那台机器当场就没了。写盘操作没有任何撤销。3.3 验证 U 盘可引导写完别急着拔最好在另一台机器或者虚拟机里试引导一次。能进到 CentOS 安装/救援菜单说明盘没问题。这一步花五分钟能省掉你在故障机前反复插拔的半小时。4. 进入救援模式并挂载原系统4.1 从 U 盘引导与救援模式选择把 U 盘插到故障机进 BIOS/BMC 设置从 U 盘启动。进入 CentOS 引导菜单后选择Troubleshooting → Rescue a CentOS system。接下来会有几个选项继续Continue自动尝试挂载原系统到/mnt/sysroot。只读挂载Read-only mount安全但没法直接改。跳过Skip手动挂载适合自动挂载失败的情况。启动 Shell直接进救援 shell。如果自动挂载成功系统会提示原系统挂在/mnt/sysroot。如果失败比如 LVM 名字特殊、分区表异常就选 Skip 或 Shell手动来。4.2 手动挂载 LVM 与普通分区CentOS 默认安装常用 LVM手动挂载步骤大致如下# 激活卷组 vgscan vgchange -ay # 查看逻辑卷 lvs # 挂载根逻辑卷假设是 /dev/centos/root mkdir -p /mnt/sysroot mount /dev/centos/root /mnt/sysroot如果是普通分区直接mount /dev/sda2 /mnt/sysroot即可。挂载完还要处理/boot、/boot/efi等独立分区以及绑定挂载/dev、/proc、/sys这样chroot进去之后系统才像活的mount /dev/sda1 /mnt/sysroot/boot for d in dev proc sys run; do mount --bind /$d /mnt/sysroot/$d; done提示/usr被删后原系统的mount命令可能也没了所以这些操作都是在救援环境里执行的用的是 U 盘里的工具不受原系统损坏影响。这正是救援盘的价值所在。4.3 chroot 进原系统前的检查chroot /mnt/sysroot之前先确认几件事根分区挂载成功ls /mnt/sysroot能看到目录结构。/usr目录现在是空的还是部分存在。有没有可用的备份或快照。如果/usr完全空了chroot进去之后你会发现连bash都跑不起来因为bash在/usr/bin/bash。这时候要么从救援盘复制一个静态编译的 shell 进去要么干脆不 chroot直接在救援环境里操作原系统的文件。5. 恢复 /usr 的几条可行路径5.1 路径一从备份或快照恢复最优如果你之前做过以下任意一种恢复会轻松很多LVM 快照lvcreate -s创建的快照可以直接挂载把/usr拷回来。rsync/打包备份有/usr的完整备份直接解压覆盖。虚拟机快照虚拟化平台层面的快照回滚即可。LVM 快照恢复示例# 挂载快照卷 mount /dev/centos/snap /mnt/snap # 把 /usr 拷回原系统 rsync -aAX /mnt/snap/usr/ /mnt/sysroot/usr/这是最干净的方式因为文件权限、SELinux 上下文、软链接都能原样保留。5.2 路径二从同版本系统复制 /usr没有备份时找一台完全相同 CentOS 版本、相同架构的机器把它的/usr打包拷过来。注意几个坑版本必须一致小版本差异可能导致库文件不匹配。架构必须一致x86_64 对 x86_64。拷过来之后要重建软链接和 SELinux 上下文。# 在健康机器上打包 tar --selinux -czpf usr.tar.gz /usr # 在救援环境解压到原系统 tar --selinux -xzpf usr.tar.gz -C /mnt/sysroot--selinux参数很关键不加的话 SELinux 上下文全乱系统起来后各种拒绝访问。5.3 路径三重装系统保留数据如果/usr彻底没了、又没有备份、又找不到同版本机器那最务实的方案其实是重装系统。但重装不等于数据全丢如果/home、/data是独立分区重装时不要格式化这些分区装完再挂回来。如果数据在根分区里先在救援环境把数据拷到外部存储再重装。我个人的判断标准是修复/usr的时间成本如果超过重装加数据迁移就果断重装。硬修一个残缺的系统后续可能埋下各种诡异问题不如一次装干净。5.4 路径四用包管理器重建仅限部分损坏如果只是/usr下部分文件被删系统还能勉强跑rpm可以尝试rpm -Va # 列出校验失败的文件针对性重装对应包 rpm -qf /usr/bin/ls但/usr大面积被删时rpm本身可能都跑不起来这条路基本走不通。所以它只适合手滑删了几个文件的轻症。6. 恢复后的收尾与验证6.1 重建软链接与 SELinux 上下文/usr恢复后别急着重启。先检查软链接ls -l /mnt/sysroot/bin /mnt/sysroot/sbin /mnt/sysroot/lib /mnt/sysroot/lib64正常应该指向/usr/bin、/usr/sbin、/usr/lib、/usr/lib64。如果丢了手动重建ln -s usr/bin /mnt/sysroot/bin ln -s usr/sbin /mnt/sysroot/sbin ln -s usr/lib /mnt/sysroot/lib ln -s usr/lib64 /mnt/sysroot/lib64SELinux 上下文用restorecon修复chroot /mnt/sysroot restorecon -Rv /usr如果restorecon也跑不起来说明/usr恢复还不完整得回头补文件。6.2 重启前的最后检查重启前建议做这几件事chroot进去后能正常执行ls、cat、bash。/etc/fstab内容正确分区 UUID 没变。引导文件/boot完整grub2-mkconfig能跑。有条件的话先在虚拟机里验证一遍再上生产。6.3 重启与观察重启后重点看能否正常进入系统。dmesg有没有库文件缺失的报错。关键服务能否启动。rpm -Va是否还有大量校验失败。如果一切正常恭喜你救回来了。如果还有零星报错多半是某些包没恢复全针对性重装即可。7. 常见问题与排查速查7.1 救援模式进不去或找不到原系统现象可能原因处理引导菜单没有 U 盘BIOS 未设置 U 盘启动进 BIOS 调整启动顺序救援模式挂载失败LVM 未激活vgscan vgchange -ay找不到根分区分区表异常用fdisk -l排查chroot 后命令全无/usr 为空从救援盘复制基础工具7.2 恢复后系统起不来的典型原因SELinux 上下文错误表现为服务启动被拒restorecon可解。软链接缺失/bin等指向错误手动重建。库版本不匹配从不同版本系统拷的/usr需换同版本。fstab 错误分区 UUID 变了进救援模式改回。7.3 独家避坑经验别在生产机上练手先在虚拟机里模拟一次rm -rf /usr把整个救援流程走通真出事时手不抖。U 盘常备做好的救援 U 盘放在机房别等出事再找。备份是唯一真理LVM 快照、定期 rsync、虚拟机快照至少有一种。rm -rf加别名保护给 root 的rm加-i或者用safe-rm能挡掉一部分手滑。操作前pwd确认删目录前先pwd确认自己在哪这个习惯救过我不止一次。8. 我个人的几点体会折腾过几次这类事故之后我最大的感受是Linux 系统的健壮是有前提的前提就是你别去动它的根基。/usr、/lib64、/etc这几个目录平时看着不起眼一旦出事就是系统级灾难。救援 U 盘和备份方案属于平时用不上、用上就是救命的东西值得每个管机器的人提前准备好。另外恢复过程本身也是对系统结构的一次深度学习。你会真正理解为什么/bin是软链接、为什么 SELinux 上下文这么重要、为什么 LVM 快照在关键时刻能救命。这些认知比单纯背几条命令有价值得多。最后分享一个小技巧如果你经常在虚拟机里做危险操作养成操作前打快照的习惯成本几乎为零收益却可能是几个小时的恢复时间。这个习惯比任何救援技巧都管用。