extundelete仅适用于未覆盖的ext3/ext4文件系统，根分区恢复成功率极低；需先确认文件系统类型、立即卸载或只读挂载目标分区，再通过inode扫描定位并恢复指定目录，最后验证文件完整性。

extundelete 只能恢复 ext3/ext4 文件系统上被删的文件或目录，且前提是删除后未被覆盖、分区未继续写入。根分区（/）上误删项目文件夹，恢复成功率极低；数据盘（如 /data）相对可行。

确认文件系统类型和目标分区

先查被删项目所在路径挂载在哪个设备上，再确认它是否为 ext3 或 ext4：

• df -T /path/to/your/project —— 查看挂载点对应的设备和文件系统类型
• cat /proc/filesystems | grep -E "ext3|ext4" —— 确认内核支持（一般默认支持）
• 如果输出中没有 ext3 或 ext4，说明该分区不是 ext 系列，extundelete 完全不适用
• 若挂载点是 /，不要直接操作；应考虑从 Live USB 启动，否则系统持续写日志会快速覆盖元数据

立即停止写入并卸载分区

这是成败关键。只要分区还以读写方式挂载，恢复概率就随秒下降：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• sudo umount /mount/point（例如 sudo umount /data）
• 若提示 “target is busy”，用 sudo fuser -v -m /mount/point 查进程，再 sudo fuser -k -m /mount/point 强制终止
• 如果无法卸载（比如是根分区），改用只读重挂载：sudo mount -o remount,ro / —— 但注意：部分系统服务可能因此异常，仅作临时应急
• 不要尝试 touch、ls -R、find 等任何可能触发磁盘 I/O 的命令

用 extundelete 恢复整个项目目录

extundelete 不支持按路径模糊匹配恢复，必须明确指定目录名或 inode。推荐先扫描再定向恢复：

• 查看可恢复项：sudo extundelete /dev/sdXN --inode 2（2 是 ext 文件系统根目录 inode）
• 逐层查 inode：sudo extundelete /dev/sdXN --inode <code>INODE_NUM，直到找到你项目目录的条目（状态显示 Deleted）
• 恢复单个目录：sudo extundelete /dev/sdXN --restore-directory /path/to/project（路径必须是删除前的完整路径，如 /data/myapp）
• 恢复后文件默认存入当前工作目录下的 RECOVERED_FILES 子目录，结构与原路径一致
• 注意：--restore-all 会把所有可恢复项都拉出来，可能包含大量垃圾文件，不建议在空间紧张时使用

恢复后验证内容完整性

恢复出来的文件只是“元数据+数据块”的拼合，不代表内容一定完好：

• 检查文件大小是否合理：ls -lh RECOVERED_FILES/path/to/project
• 对代码类文件，用 file 命令确认类型：file RECOVERED_FILES/path/to/project/src/main.py
• 打开关键文件头几行，确认没出现乱码或截断（ext4 journal 若已刷盘，小文件常能完整恢复；大文件或碎片多的容易缺块）
• 如果项目含 Git 仓库，恢复后 git status 很可能报“deleted by us”，说明工作区文件被删但 .git/index 还有记录 —— 此时 git checkout -- . 反而是更快更准的补救方式

真正难的不是执行命令，而是判断「现在还能不能救」—— 如果删完还跑了 backup 脚本、logrotate、或者有人顺手 apt update，那 inode 早被复用了。动手前先问自己：从删除到执行 umount，中间隔了多久？有没有其他进程在往那个分区写东西？