Nic*_*k J 5 linux usb data-recovery hard-drive-recovery ddrescue
有一个失败的 Windows/NTFS 驱动器。我能够通过 USB-to-IDE 电缆连接到另一台 PC，并使用 Knoppix 7.2 LiveUSB 和ddrescue/恢复大部分驱动器ddrutitliy。我已经恢复了最关键的数据。现在我将它用作学习练习，看看我是否可以使这个过程更容易，以及在不弄乱硬件的情况下我可以恢复多少。
下面是完整的叙述，但我想知道是否有人成功制作了一个脚本来处理驱动器（USB 或其他）的情况，该驱动器间歇性地或由于已知原因在救援期间中断。
使用ddru_ntfsbitmap我能够拉引导扇区和 MBR 位图以将恢复范围缩小到刚使用的文件空间（60GB 驱动器上的 16GB）。使用的命令是：
ddru_ntfsbitmap -i 32256 -m MFTDomainFile.txt /dev/sdc filelocations.txt
（-i用途63*512 = 32256。因为驱动器不会挂载以从 fdisk 找到 63，我不得不猜测直到ddru_ntfsbitmap告诉我它可以找到引导扇区。显然它通常是 63 或 2048。）
该驱动器经常中断，并且有一个驱动器部分（第一个 950MB）会在单个扇区读取错误后中断。继续需要拔出 USB-IDE 电缆并重新插入，以使驱动器显示在 /dev 中。在这台 PC 上（或者可能与 Knoppix 有关），如果驱动器断电，ddrescue继续将额外的读取尝试标记为错误，从而难以跟踪“真正的”扇区读取问题。（在另一台装有 Ubuntu 的旧电脑上，它会以某种方式检测到这一点并终止ddrescue，这是一个很好的功能，但我不知道是什么导致了这种不同的行为。）通过几次启动和重新启动，我能够ddrescue用来读取/复制大一次部分并获得大部分磁盘。（> 95% 的表现较好的部分）。使用-i和-s 我解决的选项并限制“将所有内容都标记为坏”问题的影响。
一般来说，我使用的命令是这样的：
ddrescue -S -m filelocations.txt /dev/sdc HDImage.img HDRecoverlog.txt -r2 -d -i5GB -s1GB
如果它被剪掉，它只会将该 1GB 部分标记为坏的，我可以重试添加，-AM以便它会阻止复制，或者只使用-r5. 在慢速部分，复制速度似乎并不重要，而且在进行块复制时它会更频繁地中断。
在获得所有未尝试的大部分后，允许ddrescue在驱动器更稳定的部分上运行一夜之间会在该部分中找到大多数扇区错误。ddru_ntfsfindbad（查找哪些文件有错误）在 $MFT 中报告了 20 个扇区错误，因此我使用以下命令重新运行了一夜：
ddrescue -S -m MFTDomainFile.txt /dev/sdc HDImage.img HDRecoverlog.txt -r-1 -d
这会找出所有$MFT错误，所以我跑去ddru_ntfsfindbad寻找驱动器其余部分仍然存在错误的文件：
ddru_ntfsfindbad -i 32256 -DD -HDImage.img HDRecoverlog.txt
（-DD生成一个调试日志文件，其中包含每个 inode 的扇区位置，它可以与正常结合ntfsfindbad.log以定位每个有错误的文件。）
只是让ddrescue稳定部分在整个周末运行，它在该部分发现了除两个扇区错误之外的所有错误（从周五的 1112 个错误开始）。重新运行ddru_ntfsfindbad产生了一个更小的文件错误列表。
对于硬盘的前端部分，仍有约 150MB 标记为“坏”。很多只是被跳过/未尝试，但被标记为与驱动器切断一样糟糕。使用 ntfsfindbad 日志，我可以通过以下（显然是众所周知的）痛苦过程手动定位文件：
ddrescue启动后发出命令。CTRL-C如果我听到它遇到坏扇区，则命中，否则它会如上所述丢失其位置。
CTRL-C它停靠在一个扇区，并开始有下一次。-X选项将消除对此的需要，但它停留在问题扇区而不是前进，并且永远不会越过真正糟糕的扇区。我能够以这种方式完全恢复大多数感兴趣的文件。手动定位/拆分大的未尝试部分可能会拉动整个部分而不会出错。但有时我必须重试特定错误 10-20 次。使用这个过程，除了大约 150kB 的错误之外，所有错误都被“快速”清除了。从那时起，手动重试已减少到总共约 55 个单扇区错误和 31kB。根据驱动器其余部分的行为，如果我可以刮除一些实际上的坏扇区之外的所有扇区，并且可能在替换少量文件后使整个图像正常工作（当然是 Windows/system32），我不会感到惊讶在该部分）。
我意识到这相当于一个相当幸运（尽管很少见）的情况，其中数据是可以恢复的。但是我救出的最后一个磁盘有一个非常相似的“驱动器因单个读取错误而中断”的问题。我已经阅读了许多关于如何尝试重置或重启磁盘和/或 USB 端口的帖子。从我所见，切断 USB 电源的能力高度依赖于硬件和 Linux 内核。我也意识到有硬件和服务解决方案可以帮助解决这个问题，如果成本/收益图不同，这将是值得的。
那么，是否有更好的方法来处理上述 5 步过程？这也可能使“好”部分中的初始数据抓取速度更快（更少的手动操作）。有没有更好的方法（仍然是 DIY）来解决整个过程？
小智 4
将TLER设置为 1 秒解决了我的电源循环问题：
smartctl -l scterc,10,10 /dev/sdX