在数据恢复这个行当里摸爬滚打这么多年我越来越觉得绝大多数人对于硬盘数据恢复工具的理解都停留在“扫描一下、找回文件”的魔法层面。但真正等到误删了重要文件、硬盘咔咔作响、分区表不翼而飞的时候又急得像热锅上的蚂蚁病急乱投医最后花钱买教训。作为一个既写过底层驱动、也做过商业数据恢复工具的从业者今天这篇长文我就想跟你彻底聊聊硬盘数据恢复工具的底层原理和工程实现。我不会跟你扯什么玄学也不会堆砌一堆看不懂的术语而是从数据在硬盘上到底怎么存放开始一步步拆解工具是怎么把那些看似已经消失的比特找回来的。这篇文章会覆盖硬件原理、文件系统机制、工具分类、实操流程甚至是自研工具的工程架构设计。不管你是刚入行的运维、被数据困扰的普通用户还是想自己造轮子的开发者这篇都能帮你少走弯路建立起一个清晰完整的知识框架。1. 内容整体设计与思路拆解在开始动手折腾任何数据恢复工具之前你必须先想明白一个核心问题这玩意儿到底凭什么能把数据找回来这就像医生看病如果你不知道人体的基本构造就贸然开刀那跟杀人没什么区别。数据恢复也是一样如果你不懂硬盘的物理存储逻辑和文件系统的记账规则那所谓的恢复工具在你手里也只是一堆乱码生成器。1.1 核心需求解析我们到底要从硬盘里捞什么很多时候用户的需求表述是模糊的。比如“我文件丢了帮我恢复一下”。但“文件丢了”背后的成因至少有四种恢复难度天差地别逻辑层误删文件还在硬盘上只是文件系统把名字和索引标记删了数据块可能完好无损。这种恢复成功率极高难度极低。破坏性写入覆盖文件删了之后又往同一个位置写了新数据。这时候旧文件的数据块部分或全部被覆盖神仙难救。文件系统元数据损坏比如突然断电导致目录结构错乱、分区表丢失。这种情况下数据块可能还在但“地图”没了需要工具根据文件特征去重建地图。硬件物理坏道盘片表面有损伤或者磁头老化导致物理上读不出数据。这是最棘手的情况软件层面几乎无能为力一旦强行读取可能会加剧物理损伤导致数据彻底消失。这时候一个合格的数据恢复工具它的核心需求不是“扫描”而是“评估”和“抢救”。我之前收到过一个用户的需求他说想要一个“一键恢复”工具我很直接地告诉他这种工具如果存在那一定是建立在牺牲底层数据安全的基础上。工具的第一需求永远是“只读”和“无损”而不是“快”和“炫”。在工程实现上这意味着所有的恢复动作都必须像法医解剖一样带着取证的心态去做绝对不能在被恢复的源盘上动刀。1.2 方案选型背后的考量为什么不能直接在原盘上操作这个是我反复要跟新入行的工程师强调的。我见过太多新手拿到盘就双击打开恢复软件然后对着原来的D盘一顿扫描这简直是灾难。任何对源盘有写操作的所谓“恢复”都是耍流氓。为什么会这样我们要理解文件系统的一个核心机制。以最常见的NTFS为例当你删除一个文件时系统只是将文件记录的标志位从“使用中”改为“空闲”并更新位图Bitmap文件。这些操作写入硬盘的时候占用的地方正是在原文件所在的MFT记录附近。如果此时你安装了软件、运行了扫描操作系统会频繁地写日志、写临时文件这些新写入的数据极有可能会落在待恢复文件的数据簇Cluster上。在工程实现上成熟的恢复工具无论是商业的还是开源的都有一个铁律只读挂载或以底层扇区读取的方式工作并且在扫描前强制要求对源盘做逐扇区镜像。这就像黑客精英拿到硬盘后第一时间不是翻文件而是用dd或ddrescue工具给整块盘拍一个全裸的“CT片”。后续所有的扫描和恢复逻辑都基于这个镜像文件运行。这样即便操作失误也只是损坏了镜像原始硬盘的数据还在可以无限次重试出错。我给你的第一条黄金法则工具选型时优先看它是否支持创建与恢复独立于源盘的镜像文件这是衡量工具专业度的试金石。2. 核心细节解析与实操要点好了思路理清了我们得深入到细节里去。前面说数据恢复是基于文件系统的“记账规则”那这规则到底是什么接下来我会硬核地拆解硬盘的数据布局以及恢复工具是怎么利用这些布局来做文章的。2.1 数据的微观世界从磁道到扇区硬盘就是一台精密到原子级别的“留声机”。数据存在盘片上的同心圆轨道上这些轨道叫磁道Track磁道又被划分为一段一段的圆弧叫扇区Sector。传统上每个扇区是512字节而现在大容量硬盘已经普遍采用4K扇区4096字节。但这只是物理层面的“仓储”。操作系统不能直接操作扇区它需要把扇区组合成逻辑块。这里有一个极其关键的概念叫逻辑区块寻址LBALogical Block Addressing。你可以把硬盘想象成一本巨大的、按顺序编号的空白书每一页就是一个LBA地址。文件系统的职责就是在这本空白书上写上“目录”和“内容”。数据恢复工具在工程实现上本质上就是一个狂热的LBA阅读强迫症患者。它不关心Windows告诉我D盘还有多少空间它只关心LBA 1000到2000这个区域里存贮的那些字节到底藏着什么秘密。2.2 文件系统的大脑Inode、目录项与数据块现在我们需要把视线拉高一点从物理层拉升到逻辑层。无论是什么文件系统FAT32、NTFS、ext4、APFS它们都有一个通行的且极其居家的记账逻辑数据块Data Block真正存储文件“内容”的地方比如我写下的这篇文章的文本就是存在这里。元数据Metadata描述文件身份和位置的信息包括文件名、创建时间、文件大小以及指向数据块的指针列表。比如在Linux的ext4文件系统中这个关键信息存放在Inode索引节点里在Windows的NTFS中它存放在MFT主文件表里。恢复工具的原理就是利用一种“逻辑矛盾”来工作当你删除文件时系统清除了Inode/MFT中的指针或标记但数据块里的原始字节依然安静地躺在那儿。除非被新数据覆盖否则它们就像是被撕掉了索引标签的图书馆藏书内容还在书架上只是没有被录入检索系统。2.3 恢复工具的分类与关键原理根据恢复的发生时机和底层机制市面上的工具大致分三类我建议你一定要能分辨清楚基于文件系统元数据的恢复Undelete这是最基础、成功率最高的。工具读取文件系统剩余的空闲记录比如扫描MFT未被覆盖的条目找到文件名和指向数据块的指针。如果指针还完整直接按图索骥读取数据。文件删除后没有再写入操作的话走这条路几乎是秒回。基于文件签名/内容的恢复Carving当文件系统的“账本”被格式化了或者Inode被重置了指针和名字都找不到了怎么办那就只能用“内容嗅探”了。每种文件格式JPG、PDF、ZIP都有固定的文件头File Header和文件尾File Footer。比如JPEG文件的头部固定有“FF D8 FF E0”或“FF D8 FF E1”这样的特殊字节序列。恢复工具会全盘扫描将硬盘的裸字节流当做一个巨大的字符串去寻找是否有文件头部特征码。一旦发现再从头部开始按照该格式的内部结构去分析需要读多少字节直到尾部然后强制切割出来。这种技术叫“数据雕刻Carving”它是工具清除垃圾碎片的杀手锏。基于硬件固件层级的恢复这属于深水区了涉及PC3000等专业设备直接操作硬盘的ROM和固件模块修复翻译器、重建译码表。这在工程实现上完全是另一套逻辑不适合软件工具去触碰但在选型时你要知道如果软件扫描盘一片空白且极具规律的杂音多半是固件坏了。2.4 实操关键参数选择为什么扫描那么慢以及该如何设置如果你使用过Windows下的各种恢复软件比如DiskGenius、R-Studio一定会看到针对扫描范围的设置比如“快速扫描”和“深度扫描”。这里我直接给出手动操作时的避坑参数建议扫描类型原理适用场景参数建议与工程注意点快速扫描仅读取文件系统的元数据区不扫描所有数据块。文件被误删、快速格式化后数据未被覆盖时。耗时短分钟级但无法恢复元数据被破坏的文件。特别注意不要在删除后继续往该盘灌数据。深度扫描/完整扫描逐扇区读取整个LBA地址空间对每个扇区进行文件特征签名匹配。分区被删除、格式化后再重装系统、文件元数据完全丢失。耗时极长数小时到数天会产生巨大的临时索引文件。最好通过“镜像”文件进行扫描以免硬盘过热或物理损耗。指定扩展名扫描仅扫描特定文件类型的特征码比如只找.docx或.mp4。明确知道只丢失了特定类型的文件且文件碎片化严重。优点在于快缺点在于无法恢复文件名和路径恢复出来的叫FILE0001.docx。实操心得在工程实现扫描器时必须采用分块读校验的机制。因为硬盘读头在任何意外震动或断电时极易产生逻辑坏道如果一个块读取失败就死循环工具就卡死了。所以在扫描大容量硬盘时如果工具支持设置“遇到坏道跳过大小”建议设置成256MB或512MB跳过一点碎片保住大局。3. 实操过程与核心环节实现理论讲了一堆不实际操作一下就是纸上谈兵。下面我们来复现一次完整的数据恢复实操过程。这次场景设定为一个误格式化的U盘FAT32文件系统需要找回里面的几张婚纱照RAW格式。我会用命令行工具ddrescue和开源工具TestDisk以及PhotoRec来演示。3.1 环境准备与硬件连接策略第一步不是打开软件而是准备“抢救室”。你需要准备两个设备一个是出问题的源盘U盘另一个是用于存放恢复数据的目标盘最好是移动硬盘或另一块分区充足的大容量硬盘。连接硬件的时候有一个极其重要的策略如果目标盘和源盘是相同型号的硬盘一定要通过识别符比如Linux下的/dev/sda、/dev/sdb或Windows下的磁盘编号反复确认绝对不要搞反盘符顺序。如果搞反了你要恢复的数据可能会被瞬间覆盖这种低级错误业内屡见不鲜。在Linux环境下我们先加载必要的模块并确认盘符# 查看当前系统识别的所有块设备 lsblk # 输出示例假设源盘是 /dev/sdb目标外接盘是 /dev/sdc # NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT # sdb 8:16 1 29.3G 0 disk # └─sdb1 8:17 1 29.3G 0 part # sdc 8:32 0 931.5G 0 disk看到sdb这个 29.3G 的U盘且没有挂载点说明就是我们需要的源盘。在动手前立即取消系统自动挂载行为防止系统在该盘上写入日志。# 确认挂载状态为未挂载 mount | grep sdb3.2 第一步使用 ddrescue 进行逐扇区镜像这一步是纯工程操作也是最关键的一步。我们要把/dev/sdb整盘复制到一个镜像文件中。这里我不推荐大家直接使用dd因为dd碰到坏道会直接中断而ddrescue是专门为救援设计的它能自动跳过坏道并在多次尝试中记录日志实现“先拆大件再扣细节”。# 创建镜像并生成日志文件 sudo ddrescue -d -r3 /dev/sdb /mnt/rescue_drive/udisk_image.img /mnt/rescue_drive/udisk_rescue.log参数详解-d直接读取绕过操作系统缓存虽然速度慢但能拿到最原始的物理状态。-r3对于读取失败的块重试3次。坏道区块的东西是物理损坏重试多了只会加剧盘片磨损。最后的udisk_rescue.log是日志文件如果镜像过程因断电中断下次运行该命令会先读取log文件然后从断点继续而不是从头开始。运行后你会看到类似下面的进度输出GNU ddrescue 1.23 Press Ctrl-C to interrupt ipos: 5120 B, non-trimmed: 0 B, current rate: 24412 kB/s opos: 5120 B, non-scraped: 0 B, average rate: 24412 kB/s non-tried: 31364 MB, bad-sector: 0 B, error rate: 0 B rescued: 5120 B, bad areas: 0, run time: 0s等执行完毕后我们看一眼最终汇总sudo ddrescue -d -r3 /dev/sdb /mnt/rescue_drive/udisk_image.img /mnt/rescue_drive/udisk_rescue.log如果看到rescued: 29.3 GB, bad-sector: 0 B恭喜你物理层完美。就算有少量bad-sector只要不是很大也依然有拯救余地。3.3 第二步基于镜像使用 TestDisk 修复分区表镜像文件已经躺在/mnt/rescue_drive/udisk_image.img上了。现在开始处理它。我们绝不对原盘操作而是对着镜像文件来。这里介绍一个行业协会内的神器TestDisk。它是一个基于命令行的、可移植的分区表恢复与引导区修复工具。它高度遵循我前面说的“逻辑层拯救”尤其擅长找回因为格式化或误删分区而丢失的分区表。# 首先让工具去分析这个镜像 sudo testdisk /mnt/rescue_drive/udisk_image.img进入交互菜单后你需要进行以下操作步骤我将屏幕输出翻译成人话选择“[Proceed]”以继续它会询问你要创建什么样的日志文件。选择分区表类型一般Intel(MBR) 或EFI GPT会高亮自动选中回车即可。选择菜单项“[Analyse]”进行当前分区结构的分析。接下来会显示当前的硬盘分区情况此时可能为空或错误。选择“[Quick Search]”执行快速搜索它会扫描分区表的备份或通过引导扇区定位分区。如果快速搜索找到了正确的分区按P键可以列出分区内的文件列表验证是不是我们要的分区。如果
硬盘数据恢复工具底层原理与工程实现全解析
在数据恢复这个行当里摸爬滚打这么多年我越来越觉得绝大多数人对于硬盘数据恢复工具的理解都停留在“扫描一下、找回文件”的魔法层面。但真正等到误删了重要文件、硬盘咔咔作响、分区表不翼而飞的时候又急得像热锅上的蚂蚁病急乱投医最后花钱买教训。作为一个既写过底层驱动、也做过商业数据恢复工具的从业者今天这篇长文我就想跟你彻底聊聊硬盘数据恢复工具的底层原理和工程实现。我不会跟你扯什么玄学也不会堆砌一堆看不懂的术语而是从数据在硬盘上到底怎么存放开始一步步拆解工具是怎么把那些看似已经消失的比特找回来的。这篇文章会覆盖硬件原理、文件系统机制、工具分类、实操流程甚至是自研工具的工程架构设计。不管你是刚入行的运维、被数据困扰的普通用户还是想自己造轮子的开发者这篇都能帮你少走弯路建立起一个清晰完整的知识框架。1. 内容整体设计与思路拆解在开始动手折腾任何数据恢复工具之前你必须先想明白一个核心问题这玩意儿到底凭什么能把数据找回来这就像医生看病如果你不知道人体的基本构造就贸然开刀那跟杀人没什么区别。数据恢复也是一样如果你不懂硬盘的物理存储逻辑和文件系统的记账规则那所谓的恢复工具在你手里也只是一堆乱码生成器。1.1 核心需求解析我们到底要从硬盘里捞什么很多时候用户的需求表述是模糊的。比如“我文件丢了帮我恢复一下”。但“文件丢了”背后的成因至少有四种恢复难度天差地别逻辑层误删文件还在硬盘上只是文件系统把名字和索引标记删了数据块可能完好无损。这种恢复成功率极高难度极低。破坏性写入覆盖文件删了之后又往同一个位置写了新数据。这时候旧文件的数据块部分或全部被覆盖神仙难救。文件系统元数据损坏比如突然断电导致目录结构错乱、分区表丢失。这种情况下数据块可能还在但“地图”没了需要工具根据文件特征去重建地图。硬件物理坏道盘片表面有损伤或者磁头老化导致物理上读不出数据。这是最棘手的情况软件层面几乎无能为力一旦强行读取可能会加剧物理损伤导致数据彻底消失。这时候一个合格的数据恢复工具它的核心需求不是“扫描”而是“评估”和“抢救”。我之前收到过一个用户的需求他说想要一个“一键恢复”工具我很直接地告诉他这种工具如果存在那一定是建立在牺牲底层数据安全的基础上。工具的第一需求永远是“只读”和“无损”而不是“快”和“炫”。在工程实现上这意味着所有的恢复动作都必须像法医解剖一样带着取证的心态去做绝对不能在被恢复的源盘上动刀。1.2 方案选型背后的考量为什么不能直接在原盘上操作这个是我反复要跟新入行的工程师强调的。我见过太多新手拿到盘就双击打开恢复软件然后对着原来的D盘一顿扫描这简直是灾难。任何对源盘有写操作的所谓“恢复”都是耍流氓。为什么会这样我们要理解文件系统的一个核心机制。以最常见的NTFS为例当你删除一个文件时系统只是将文件记录的标志位从“使用中”改为“空闲”并更新位图Bitmap文件。这些操作写入硬盘的时候占用的地方正是在原文件所在的MFT记录附近。如果此时你安装了软件、运行了扫描操作系统会频繁地写日志、写临时文件这些新写入的数据极有可能会落在待恢复文件的数据簇Cluster上。在工程实现上成熟的恢复工具无论是商业的还是开源的都有一个铁律只读挂载或以底层扇区读取的方式工作并且在扫描前强制要求对源盘做逐扇区镜像。这就像黑客精英拿到硬盘后第一时间不是翻文件而是用dd或ddrescue工具给整块盘拍一个全裸的“CT片”。后续所有的扫描和恢复逻辑都基于这个镜像文件运行。这样即便操作失误也只是损坏了镜像原始硬盘的数据还在可以无限次重试出错。我给你的第一条黄金法则工具选型时优先看它是否支持创建与恢复独立于源盘的镜像文件这是衡量工具专业度的试金石。2. 核心细节解析与实操要点好了思路理清了我们得深入到细节里去。前面说数据恢复是基于文件系统的“记账规则”那这规则到底是什么接下来我会硬核地拆解硬盘的数据布局以及恢复工具是怎么利用这些布局来做文章的。2.1 数据的微观世界从磁道到扇区硬盘就是一台精密到原子级别的“留声机”。数据存在盘片上的同心圆轨道上这些轨道叫磁道Track磁道又被划分为一段一段的圆弧叫扇区Sector。传统上每个扇区是512字节而现在大容量硬盘已经普遍采用4K扇区4096字节。但这只是物理层面的“仓储”。操作系统不能直接操作扇区它需要把扇区组合成逻辑块。这里有一个极其关键的概念叫逻辑区块寻址LBALogical Block Addressing。你可以把硬盘想象成一本巨大的、按顺序编号的空白书每一页就是一个LBA地址。文件系统的职责就是在这本空白书上写上“目录”和“内容”。数据恢复工具在工程实现上本质上就是一个狂热的LBA阅读强迫症患者。它不关心Windows告诉我D盘还有多少空间它只关心LBA 1000到2000这个区域里存贮的那些字节到底藏着什么秘密。2.2 文件系统的大脑Inode、目录项与数据块现在我们需要把视线拉高一点从物理层拉升到逻辑层。无论是什么文件系统FAT32、NTFS、ext4、APFS它们都有一个通行的且极其居家的记账逻辑数据块Data Block真正存储文件“内容”的地方比如我写下的这篇文章的文本就是存在这里。元数据Metadata描述文件身份和位置的信息包括文件名、创建时间、文件大小以及指向数据块的指针列表。比如在Linux的ext4文件系统中这个关键信息存放在Inode索引节点里在Windows的NTFS中它存放在MFT主文件表里。恢复工具的原理就是利用一种“逻辑矛盾”来工作当你删除文件时系统清除了Inode/MFT中的指针或标记但数据块里的原始字节依然安静地躺在那儿。除非被新数据覆盖否则它们就像是被撕掉了索引标签的图书馆藏书内容还在书架上只是没有被录入检索系统。2.3 恢复工具的分类与关键原理根据恢复的发生时机和底层机制市面上的工具大致分三类我建议你一定要能分辨清楚基于文件系统元数据的恢复Undelete这是最基础、成功率最高的。工具读取文件系统剩余的空闲记录比如扫描MFT未被覆盖的条目找到文件名和指向数据块的指针。如果指针还完整直接按图索骥读取数据。文件删除后没有再写入操作的话走这条路几乎是秒回。基于文件签名/内容的恢复Carving当文件系统的“账本”被格式化了或者Inode被重置了指针和名字都找不到了怎么办那就只能用“内容嗅探”了。每种文件格式JPG、PDF、ZIP都有固定的文件头File Header和文件尾File Footer。比如JPEG文件的头部固定有“FF D8 FF E0”或“FF D8 FF E1”这样的特殊字节序列。恢复工具会全盘扫描将硬盘的裸字节流当做一个巨大的字符串去寻找是否有文件头部特征码。一旦发现再从头部开始按照该格式的内部结构去分析需要读多少字节直到尾部然后强制切割出来。这种技术叫“数据雕刻Carving”它是工具清除垃圾碎片的杀手锏。基于硬件固件层级的恢复这属于深水区了涉及PC3000等专业设备直接操作硬盘的ROM和固件模块修复翻译器、重建译码表。这在工程实现上完全是另一套逻辑不适合软件工具去触碰但在选型时你要知道如果软件扫描盘一片空白且极具规律的杂音多半是固件坏了。2.4 实操关键参数选择为什么扫描那么慢以及该如何设置如果你使用过Windows下的各种恢复软件比如DiskGenius、R-Studio一定会看到针对扫描范围的设置比如“快速扫描”和“深度扫描”。这里我直接给出手动操作时的避坑参数建议扫描类型原理适用场景参数建议与工程注意点快速扫描仅读取文件系统的元数据区不扫描所有数据块。文件被误删、快速格式化后数据未被覆盖时。耗时短分钟级但无法恢复元数据被破坏的文件。特别注意不要在删除后继续往该盘灌数据。深度扫描/完整扫描逐扇区读取整个LBA地址空间对每个扇区进行文件特征签名匹配。分区被删除、格式化后再重装系统、文件元数据完全丢失。耗时极长数小时到数天会产生巨大的临时索引文件。最好通过“镜像”文件进行扫描以免硬盘过热或物理损耗。指定扩展名扫描仅扫描特定文件类型的特征码比如只找.docx或.mp4。明确知道只丢失了特定类型的文件且文件碎片化严重。优点在于快缺点在于无法恢复文件名和路径恢复出来的叫FILE0001.docx。实操心得在工程实现扫描器时必须采用分块读校验的机制。因为硬盘读头在任何意外震动或断电时极易产生逻辑坏道如果一个块读取失败就死循环工具就卡死了。所以在扫描大容量硬盘时如果工具支持设置“遇到坏道跳过大小”建议设置成256MB或512MB跳过一点碎片保住大局。3. 实操过程与核心环节实现理论讲了一堆不实际操作一下就是纸上谈兵。下面我们来复现一次完整的数据恢复实操过程。这次场景设定为一个误格式化的U盘FAT32文件系统需要找回里面的几张婚纱照RAW格式。我会用命令行工具ddrescue和开源工具TestDisk以及PhotoRec来演示。3.1 环境准备与硬件连接策略第一步不是打开软件而是准备“抢救室”。你需要准备两个设备一个是出问题的源盘U盘另一个是用于存放恢复数据的目标盘最好是移动硬盘或另一块分区充足的大容量硬盘。连接硬件的时候有一个极其重要的策略如果目标盘和源盘是相同型号的硬盘一定要通过识别符比如Linux下的/dev/sda、/dev/sdb或Windows下的磁盘编号反复确认绝对不要搞反盘符顺序。如果搞反了你要恢复的数据可能会被瞬间覆盖这种低级错误业内屡见不鲜。在Linux环境下我们先加载必要的模块并确认盘符# 查看当前系统识别的所有块设备 lsblk # 输出示例假设源盘是 /dev/sdb目标外接盘是 /dev/sdc # NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT # sdb 8:16 1 29.3G 0 disk # └─sdb1 8:17 1 29.3G 0 part # sdc 8:32 0 931.5G 0 disk看到sdb这个 29.3G 的U盘且没有挂载点说明就是我们需要的源盘。在动手前立即取消系统自动挂载行为防止系统在该盘上写入日志。# 确认挂载状态为未挂载 mount | grep sdb3.2 第一步使用 ddrescue 进行逐扇区镜像这一步是纯工程操作也是最关键的一步。我们要把/dev/sdb整盘复制到一个镜像文件中。这里我不推荐大家直接使用dd因为dd碰到坏道会直接中断而ddrescue是专门为救援设计的它能自动跳过坏道并在多次尝试中记录日志实现“先拆大件再扣细节”。# 创建镜像并生成日志文件 sudo ddrescue -d -r3 /dev/sdb /mnt/rescue_drive/udisk_image.img /mnt/rescue_drive/udisk_rescue.log参数详解-d直接读取绕过操作系统缓存虽然速度慢但能拿到最原始的物理状态。-r3对于读取失败的块重试3次。坏道区块的东西是物理损坏重试多了只会加剧盘片磨损。最后的udisk_rescue.log是日志文件如果镜像过程因断电中断下次运行该命令会先读取log文件然后从断点继续而不是从头开始。运行后你会看到类似下面的进度输出GNU ddrescue 1.23 Press Ctrl-C to interrupt ipos: 5120 B, non-trimmed: 0 B, current rate: 24412 kB/s opos: 5120 B, non-scraped: 0 B, average rate: 24412 kB/s non-tried: 31364 MB, bad-sector: 0 B, error rate: 0 B rescued: 5120 B, bad areas: 0, run time: 0s等执行完毕后我们看一眼最终汇总sudo ddrescue -d -r3 /dev/sdb /mnt/rescue_drive/udisk_image.img /mnt/rescue_drive/udisk_rescue.log如果看到rescued: 29.3 GB, bad-sector: 0 B恭喜你物理层完美。就算有少量bad-sector只要不是很大也依然有拯救余地。3.3 第二步基于镜像使用 TestDisk 修复分区表镜像文件已经躺在/mnt/rescue_drive/udisk_image.img上了。现在开始处理它。我们绝不对原盘操作而是对着镜像文件来。这里介绍一个行业协会内的神器TestDisk。它是一个基于命令行的、可移植的分区表恢复与引导区修复工具。它高度遵循我前面说的“逻辑层拯救”尤其擅长找回因为格式化或误删分区而丢失的分区表。# 首先让工具去分析这个镜像 sudo testdisk /mnt/rescue_drive/udisk_image.img进入交互菜单后你需要进行以下操作步骤我将屏幕输出翻译成人话选择“[Proceed]”以继续它会询问你要创建什么样的日志文件。选择分区表类型一般Intel(MBR) 或EFI GPT会高亮自动选中回车即可。选择菜单项“[Analyse]”进行当前分区结构的分析。接下来会显示当前的硬盘分区情况此时可能为空或错误。选择“[Quick Search]”执行快速搜索它会扫描分区表的备份或通过引导扇区定位分区。如果快速搜索找到了正确的分区按P键可以列出分区内的文件列表验证是不是我们要的分区。如果
