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/sdb，ISO 是 CentOS-DVD.iso sudo dd if=CentOS-DVD.iso of=/dev/sdb bs=4M status=progress oflag=sync几个关键点：
of=后面是整块设备（/dev/sdb），不是分区（/dev/sdb1）。bs=4M是块大小，兼顾速度和稳定性，太小慢、太大某些 U 盘会出错。oflag=sync保证数据真正落盘再返回，避免拔盘时还没写完。- 写完执行
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 快照在关键时刻能救命。这些认知，比单纯背几条命令有价值得多。
最后分享一个小技巧：如果你经常在虚拟机里做危险操作，养成"操作前打快照"的习惯，成本几乎为零，收益却可能是几个小时的恢复时间。这个习惯，比任何救援技巧都管用。
