立即停止写入是数据恢复的前提，误删后任何新文件创建、日志滚动、命令执行甚至bash历史写入都可能覆盖残留数据，实测apt update即可导致30+文本文件永久丢失。
立即停止写入：这是所有操作的前提
发现误删后，任何新文件创建、日志滚动、ls、df 甚至 Bash 历史记录写入，都可能触发元数据更新或缓存刷盘，覆盖残留数据块。这不是危言耸听——实测中，执行一次 apt update 就足以让 30+ 个刚删的文本文件永久丢失。
正确做法是：立刻关闭终端、不要敲任何命令；如果系统仍在运行且你有 root 权限，优先执行 sync 强制刷缓存，然后尽快进入只读状态或关机。
用 mount -o remount,ro 切换为只读挂载
若目标分区（比如 /dev/sda2）已挂载在 /home，且你还可登录，最快速有效的保护手段就是将其设为只读：
sudo mount -o remount,ro /dev/sda2
注意：/dev/sda2 必须替换成你实际的设备名；不能对根分区（/）直接 remount,ro（会失败），此时应改用 Live USB 启动后操作。
常见错误：
- 误对
/执行该命令，报错后慌乱重启——反而触发 journal 写入，扩大破坏 - 未确认挂载点，把
/dev/sda1的只读设置 applied 到/boot，而真正要恢复的/data分区仍在读写
卸载分区（umount）比只读更彻底，但需满足条件
umount 是比 remount,ro 更干净的保护方式，因为它完全切断文件系统驱动与磁盘的交互。但前提是：
- 该分区没有正在运行的进程占用（
lsof +D /path可查） - 不是根分区、
/boot、/proc等系统必需挂载点 - 你有物理/远程控制权，能接受该路径下服务中断（比如
/var/www卸载后 Nginx 报 500）
执行示例：
sudo lsof +D /data && echo "busy" || sudo umount /data
如果提示 target is busy，别强行 -l（lazy umount），那只是延迟卸载，底层仍可能写入。
Live USB 启动是最稳妥的“离线保护”方式
当你无法确定当前系统是否静默写入（比如 systemd-journald、rsyslog、auditd 在后台活动），或目标是根分区，唯一可靠方案是用 Live USB 启动，从外部访问磁盘。
关键动作顺序：
- 下载并制作带
extundelete/photorec的发行版（如 SystemRescueCD 或自定义 Ubuntu Live） - 启动后先运行
sudo fdisk -l确认目标设备（如/dev/nvme0n1p2） - 用
sudo mount -o ro /dev/nvme0n1p2 /mnt只读挂载（不加noatime等额外选项） - 所有恢复命令都在
/mnt下操作，输出目录必须指向另一块盘（如 U 盘），绝不可写回原设备
容易被忽略的一点：Live 系统默认可能自动挂载所有分区为读写，务必检查 mount | grep rw，发现非只读立即 sudo umount 并重挂。
