我用它ddrescue
来从硬盘恢复文件。详情:
- 500GB SATA 硬盘,
- 2 个分区(例如
sdb2
)sdb3
— 每个分区约有 200 GB 的数据, - 用 SATA 适配器连接到 USB,
- 跑步:
sudo ddrescue -d /dev/sdb2 sdb2.img sdb2.logfile --force -R
。
从我的经历来看,磁盘损坏严重:
- 需要很长时间才能挂载和浏览。
- 间歇性地失去响应。
- 逐个复制文件不太幸运。
我已经ddrescue
在每个分区上运行并看到了一些奇怪的事情,但这给了我希望。
ddrescue
似乎只是在各个时间点挂起,即ipos
和opos
不动, 也不动run time
。 当前速率保持很高且不变。 这是怎么回事? 驱动器是否在一段时间内完全没有响应?- 很多时候,
ddrescue
它无法挽救任何东西,而且last sucessful read
会开始计算很长时间——实际上是无限期的。当这种情况发生时^C
,我会关闭驱动器,然后ddrescue
重新启动。令人惊讶的是,它立即开始以非常高的速度成功挽救文件。有时这种情况会持续,有时几秒钟后它就死机了。
它看起来像这样:
rescued: 10970 MB, errsize: 338 MB, current rate: 15073 kB/s
ipos: 191426 MB, errors: 3806, average rate: 15612 kB/s
opos: 191426 MB, run time: 1.65 m, successful read: 0 s ago
过了一会儿:
rescued: 11402 MB, errsize: 600 MB, current rate: 0 B/s
ipos: 144382 MB, errors: 7149, average rate: 4299 kB/s
opos: 144382 MB, run time: 7.66 m, successful read: 2.06 m ago
驱动器插入后一段时间内读取完全正常,这让我认为这里除了坏扇区之外还有其他问题。例如,我可以编写一个 bash 脚本来ddrescue
频繁地关闭电源并重新启动吗?这会杀死驱动器吗?为了便于了解,我采用了一些实践这篇文章关于ddrescue
。
答案1
SATA 转 USB 适配器各不相同。有些适配器在遇到 I/O 错误时会忘记磁盘,而有些适配器则会返回 I/O 错误并继续。根据您使用的适配器,行为范围很广。
我认为您的系统正在阻止所有 I/O,直到电源循环为止。
您可能无法通过命令行物理断开并重新连接适配器来重置其电源状态,但您可以尝试重置 USB 设备或 USB 端口。
如果这不起作用,我建议直接通过 SATA 插入硬盘,然后ddrescue
在通过 SATA 插入硬盘的情况下运行。这样,您就可以绕过 USB 适配器,因为 USB 适配器似乎每次出现错误时都会卡住。