能抢救，前提是系统未崩溃、关键进程仍在运行且未重启；立即执行mount -o remount,ro /锁定根分区，再通过/proc/PID/fd/复制被删但仍在占用的文件，切忌使用extundelete等需卸载分区的工具。
还能抢救，前提是系统没崩溃、关键进程还在跑、你没按重启。这时候别管“恢复全部”，先保住 /proc 里还开着的文件句柄——很多被删的文件其实还活着，只是目录项没了。
立刻停写并锁定根分区
只要终端还响应，马上执行：mount -o remount,ro /
这条命令把根文件系统切为只读，阻止日志、tmp、cron 等后台任务覆盖已释放的磁盘块。别等“再看看”，sync 后也得立刻挂只读。如果 mount 命令已被删（/bin 下没了），就用绝对路径：/usr/bin/mount -o remount,ro / 或 /sbin/mount -o remount,ro /（cd 和 ls 通常还在，因为它们是 shell 内置或在 /usr/bin）。
从 /proc/PID/fd 下抢救正在被进程占用的文件
这是最可能拿回完整内容的途径，尤其对数据库、日志、配置文件有效：
• 先用 ps aux | grep 找关键进程 PID（比如 mysqld、postgres、nginx）
• 进入 /proc/<pid>/fd/</pid>，用 ls -l 查看哪些 fd 指向已删除但仍在使用的文件（输出里会带 (deleted)）
• 用 cp /proc/<pid>/fd/<fd_num> /safe/path/recovered_file</fd_num></pid> 直接拷出——内容完整，连时间戳和权限都不用猜
• 注意：一旦该进程退出，对应 fd 就失效，文件真正丢失
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
别碰 extundelete / xfs_restore 这类工具
这些工具要求目标分区卸载（umount），但你根本没法卸载 /；强行操作会导致系统立即卡死或 panic。
• extundelete 必须在 unmounted 的 ext3/ext4 分区上运行，现在不现实
• xfs_restore 依赖 XFS 日志且需备份元数据，误删后无日志可溯
• testdisk 或 photorec 虽支持在线扫描，但只能恢复文件内容，丢目录结构和文件名，且扫描过程本身就会大量读写磁盘，风险远大于收益
抢救完立刻提取关键数据，别留恋系统
抢救目标不是“让系统复活”，而是把能拿的拿走：
• 优先拷出 /etc 下的配置（/etc/passwd、/etc/shadow、/etc/fstab、服务配置）
• 用 find /proc/*/fd -ls 2>/dev/null | grep deleted 扫一遍所有 (deleted) 句柄，批量复制
• 把数据拷到外部存储（U盘、NFS、远程 rsync），别存回本机任何分区
• 完成后直接关机，不要重启——重启会触发 init 重新挂载、写日志、加载模块，大概率覆盖残留数据
最常被忽略的一点：抢救窗口期极短，/proc/<pid>/fd</pid> 方式只对“删时正被打开”的文件有效；而一旦你执行了 systemctl restart、reboot、甚至 journalctl -f，就等于亲手把最后的机会关上了。
