extundelete仅支持ext3/ext4，因其依赖其日志（journal）和inode状态恢复被删文件；必须立即只读挂载，防止新写入覆盖未清除的数据块，否则恢复失败。
能恢复，但只在数据块未被覆盖的前提下成立；一旦分区继续写入，成功率断崖式下跌。
extundelete 为什么只支持 ext3/ext4，且必须立刻挂载为只读
extundelete 的恢复逻辑依赖 ext3/ext4 的日志（journal）和 inode 状态。它通过扫描 journal 中的删除记录，定位“链接数为 0 但数据块仍有效”的文件，再重建目录项与数据块的映射。这个过程要求：文件系统结构未被破坏、inode 和 block 未被新数据覆盖。
所以第一步永远是：mount -o remount,ro /dev/sdX（或对应挂载点）。如果删的是根分区且系统还在跑，优先执行该命令；如果是非系统盘（如 /data），可直接 umount /dev/sdX 再操作。
常见错误现象：
- 没卸载/没设只读就直接跑
extundelete，工具报错或恢复出空文件 - 误以为“重启能重来”，结果重启后 journal 被清空、空闲块被分配，恢复窗口彻底关闭
- 在原盘上直接
--restore-all，恢复过程本身产生写入，覆盖待恢复数据
恢复单个文件 vs 恢复整个目录，路径写法有坑
extundelete 对路径的解析是基于原始文件系统快照的，不是当前 shell 的工作目录。它要求你指定「删除前该文件在文件系统中的绝对路径」，且不能带挂载点前缀。
例如，你要恢复 /data/app/upload/2026-06-28/a9/7c/xxx.pdf，命令应为：
extundelete /dev/vdb1 --restore-file data/app/upload/2026-06-28/a9/7c/xxx.pdf
注意：data/app/... 前面没有 /，因为 /dev/vdb1 挂载点就是 /data，工具内部按设备镜像的根来算路径。
多个要点：
- 恢复目录用
--restore-directory data/app/upload/2026-06-28，同样不加开头斜杠 - 如果目录名含空格或特殊字符，必须用引号包裹整个路径参数
- 恢复出来的文件默认放在当前目录下的
RECOVERED_FILES子目录里，不是原位置 - 若提示
No files to restore，大概率是 journal 已被覆盖，或该路径在删除前根本不存在（比如变量为空导致rm -rf $DIR/*实际删了/*）
文件名丢失时，photorec 是备选，但得接受无路径无扩展名
当 extundelete 找不到目录项（比如 rm -rf * 后又写了新日志），文件名和层级就没了。这时只能靠文件签名（magic bytes）硬捞，photorec 就是干这个的。
它不看文件系统结构，直接扫描磁盘块，识别 PDF、JPEG、SQL、TXT 等几百种格式的起始特征。但代价是：
- 恢复出的文件统一命名为
f0000000.jpg、f0000001.pdf这类，原始名全丢 - 目录结构完全扁平化，所有文件塞进一个文件夹
- 可能恢复出大量碎片或残缺文件（比如半截 PDF）
- 对 SSD 需格外谨慎：若启用了 TRIM 或 discard，底层块可能已被固件标记为无效并擦除，photorec 也扫不到
运行前务必确认目标设备是只读镜像（如 /mnt/recover/vdb1.img），而非原盘。
别忽略 lsof：正在被进程打开的文件其实还能捞
哪怕文件已被 rm 删除，只要还有进程持有它的文件描述符（fd），数据就仍在内存+磁盘上，且不会被覆盖。这是最干净、最可靠的恢复路径之一。
立即执行：lsof +L1（列出所有链接数为 0 的打开文件），你会看到类似：
nginx 1234 root 7w REG 253,1 1048576 1835127 /data/app/upload/2026-06-28/a9/7c/xxx.pdf (deleted)
此时可通过 /proc/1234/fd/7 直接拷贝内容：
cp /proc/1234/fd/7 /tmp/xxx.pdf.recovered
关键点：
- 这个方法不依赖文件系统类型，XFS/Btrfs 也适用
- 必须在进程还活着、fd 未关闭时操作；一旦 nginx reload 或服务重启，fd 就释放了
- 对数据库、日志轮转等长期运行进程特别有效，但对已退出的脚本无效
真正难救的，是删完就重启、删完就写入新数据、删完就没人盯着进程状态的那几秒钟——那不是技术问题，是响应节奏问题。
