免费数据恢复完整指南：误删文件怎么找回来，分区修复手把手教你用 TestDisk 和 PhotoRec

免费数据恢复完整指南：误删文件怎么找回来，分区修复手把手教你用 TestDisk 和 PhotoRec

【免费下载链接】testdiskTestDisk & PhotoRec项目地址: https://gitcode.com/gh_mirrors/te/testdisk

前晚你整理硬盘，手一抖把整个文件夹拖进了回收站，清空，确认。今晚备份时发现照片全没了。或者更糟：插上移动硬盘，系统直接弹出"磁盘未初始化，是否格式化？"——点错一下，三年数据全毁。这两种情况，都是 TestDisk 和 PhotoRec 的主场。前者专修磁盘的分区表和引导记录，后者专从扇区里按文件签名把内容捞出来。两个工具全部免费开源，下面按真实事故流程带你走一遍。

先保现场：救数据的第一步不是救数据

别急着装工具。做三件事，顺序不能乱：

1. 立刻停止对该盘的一切写入。能拔掉就拔，能卸载就卸载。误删后，数据大多还躺在磁盘上，只是索引被抹了；你一保存新文件，覆盖就从这一刻开始。这一步做错，原始数据就真的没了。
2. 确认设备名。用lsblk或fdisk -l看清楚你要操作的是/dev/sdb还是/dev/sdb1，是整盘还是分区。选错设备，后果比误删还严重。
3. 判断盘是否健康。运行smartctl -a /dev/sdb看 SMART 信息。有坏道、读取卡顿的盘，先别动它，走后面镜像流程。机械盘数据"只是索引没了"的假设，建立在盘体完好之上。

选对工具：修容器还是捞内容

一个比喻帮你分清楚。磁盘是个集装箱，分区表是集装箱外墙上贴的货单，文件内容是箱子里的货物。

TestDisk 修的是货单。它扫描整块盘，识别 MBR（Intel）、GPT、BSD、Apple、Solaris 等分区表格式，把丢失、错位的分区重新定位出来，再写回一份正确的分区表。分区消失、"未初始化"、装双系统后开不了机，都是它的活。

PhotoRec 捞的是货物。它根本不管文件系统，直接一扇区一扇区地读，靠文件头签名（file carving）认出"这块数据是个 JPEG"。好处是分区彻底没了也能干活；代价是文件名和目录结构没了，恢复出来只能靠内容辨认。

组合打法：先 TestDisk 把分区修好，能直接访问的数据原样回来；修不回来的部分，再上 PhotoRec 做文件级打捞。

装好工具：一条命令或四步编译

大多数发行版直接装现成的：

# Ubuntu / Debian sudo apt-get install testdisk # Arch Linux sudo pacman -S testdisk # macOS brew install testdisk

装完testdisk和photorec两个命令都在。想要最新版本就自己编译：

git clone https://gitcode.com/gh_mirrors/te/testdisk cd testdisk ./autogen.sh ./configure make sudo make install

一次完整恢复走查：误格式化的 U 盘

假设/dev/sdb1是个被误格式化的 U 盘分区，里面是工作文档。

第一步，TestDisk 尝试把分区找回来：

sudo testdisk /dev/sdb

界面里的按键顺序，跟着走：

1. [Create]—— 生成 testdisk.log 日志，排查问题全靠它；
2. 分区表类型 —— 绝大多数选Intel，苹果设备或较新的磁盘选GPT；
3. [Analyze]进入分析，再选Quick Search快速搜索；
4. 扫描结果里找到丢失的分区，按P标记为 Primary，确认起始/结束位置和你记忆里的分区大小对得上；
5. 按[Write]把新分区表写回磁盘，重启，拔 U 盘再插。

这一步成功，目录结构和文件名原封不动，收工。分区表彻底找不回来的情况，进入第二步。

第二步，PhotoRec 按签名捞文件：

sudo photorec /log /d /data/recovery /dev/sdb1

/d后面是恢复文件存放目录，/log让全程留痕。进交互界面后：选中分区 → 文件系统类型拿不准就选Other→ 确认保存位置 → 按Search开扫 → 跑完进度按 Enter。中途想停，Ctrl+C。

恢复结果会按类型丢进recup_dir.d这类子目录（JPEG 进 jpeg 目录，文档进 oth 目录），文件名全是 f001234.jpg 这种编号——所以恢复后得花点时间按内容和修改时间重新归档。

参数速查与提速排错

三个实用建议：

• 缩小扫描范围。交互界面里可以只扫某个分区或指定磁盘区域，整盘扫慢是常态，范围越准越快。
• 报问题前留好证据。带上/log /debug跑一遍完整流程，日志直接交给维护者，比描述快十倍。
• ⚠️ 坏道盘先镜像再操作。ddrescue /dev/sda /data/sda.img /data/sda.log会跳过读不动的坏块并记录进度，中断后能接着跑。之后所有恢复对着.img做，原盘不再承受任何读压力。

🚨唯一会要命的错误：把恢复目录放在被恢复的盘上。扫描过程要大量写入结果，一旦目标落在同一块物理盘，正在恢复的数据被当场覆盖。动手前df -h确认目标目录在另一块盘上，这一步没有补救措施。

为什么有时就是救不回来

讲几个残酷的真相，免得你白忙。

SSD 是重灾区。机械盘删除文件只是划掉目录条目，数据还躺在扇区里慢慢等被覆盖。SSD 的 TRIM 机制完全不同——删除后主控会在很短的时间内把对应物理块直接清零，这不是"还没被覆盖"，而是"被硬件抹掉了"。所以 SSD 误删后黄金窗口只有几分钟，发现得晚，基本只能靠备份。

覆盖写没有回头路。机械盘上，只要新文件没写到那个位置，签名还在就能捞。但恢复工具分不清"这是老数据"还是"这是新数据"，如果你误删后继续往盘里存东西，覆盖从写入那一刻起就不可逆了。这也是为什么前面反复强调先停写。

碎片化文件会缺胳膊少腿。大文件在磁盘上是分散存放的，签名扫描找到文件头后按顺序往后读，遇到碎片断点就切了。所以恢复出的大文件可能只有前半段——恢复后务必先抽查关键文件能不能正常打开，再整体归档。

收尾核对清单

恢复结束，逐项过一遍：

• 恢复目录确认在另一块物理盘（df -h复核过）
• 运行全程带/log，日志已妥善保存
• 抽查关键文件（图片能打开、压缩包能解开、文档能读完）
• SSD 误删场景下，盘上已停止一切写入
• 坏道盘是先在 ddrescue 镜像上操作的原盘
• 恢复文件已按内容重新归档，不再是 f000001.jpg 的编号状态

最后一条建议值得刻进习惯：定期备份，每季度用testdisk /list之类的工具把分区表导出留档一份。再强的恢复工具，排序也永远在备份后面。

对想动手改代码的人：src/partgpt.c、src/parti386.c 等 part*.c 是各分区表格式的解析模块，src/file_xxx.c 每个文件对应一种文件类型签名，统一识别引擎在 src/filegen.c，文档在 doc/ 和 INSTALL 里，有兴趣可以顺着看。

【免费下载链接】testdiskTestDisk & PhotoRec项目地址: https://gitcode.com/gh_mirrors/te/testdisk