![解释 safecopy 到设备文件的输出](https://linux22.com/image/219848/%E8%A7%A3%E9%87%8A%20safecopy%20%E5%88%B0%E8%AE%BE%E5%A4%87%E6%96%87%E4%BB%B6%E7%9A%84%E8%BE%93%E5%87%BA.png)
所以最近我们有一个快要死的硬盘驱动器,我们试图从使用中复制所有数据safecopy
。我能找到的文档以及任何指南都指定safecopy
输出必须是图像文件。该命令已处理,但仅XXX
作为输出产生,表明数百和数千个块的读取不成功。显然这是不正确的,因为驱动器仍然可以安装并且大多数文件都是可读的。接下来我重试,指定 HDD 分区 ( /dev/sdb2
) 作为输出,正如有人建议的那样(我再也找不到该线程了,那是一个多星期前的事了)。命令运行,输出成功读取,预计在 5 天多的时间内完成。
现在驱动器上有所有恢复的数据,但分区已变得无法读取。我们无法重复恢复,因为损坏的驱动器很快就死掉了(磁头崩溃,而且是一个相当暴力的情况),我们必须以某种方式从另一个 HDD 获取数据,自从命令完成并写入以来,该数据肯定就在那里隔断上方。是否有可能以某种方式检索它?我在想,如果预期目标是一个.img
文件,那么将原始数据从设备文件复制到 with.img
可能dd
会给我们带来该命令应该让我们开始的“预期结果”(即safecopy
在文件形式.img
而不是在设备上),但dd
在操作进行了百分之几后就冻结了,甚至在几个小时后也没有恢复。
由于在易失性系统上运行,确切的副本和输出丢失了,但根据我记得的设备和参数,它一定是丢失的sudo safecopy --stage1 -b 4096 -R 2 /dev/sda2 /dev/sdb2
,即执行第一阶段副本,并从/dev/sda2
(损坏)到dev/sdb2
(备份)添加了两次重试,两者都有块大小为 4096 字节。...
据我所知,输出大部分产生,表明块读取成功。输出结束时safecopy
通知我它已成功完成,写入了约 3TB 的数据。
sudo file -s /dev/sdb2
仅产生错误消息/dev/sdb2: ASCII text, with very long lines, with no line terminators
,重试可以hexdump -C /dev/sdb2
更深入地了解设备上的内容:
00000000 42 61 44 62 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |BaDbLoCkBaDbLoCk|
*
01000030 42 61 44 62 4c 6f 43 6b 10 00 00 00 4c 6f 43 6b |BaDbLoCk....LoCk|
01000040 c4 7b 00 00 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |.{..LoCkBaDbLoCk|
01000050 42 61 44 62 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |BaDbLoCkBaDbLoCk|
*
0101ef10 c8 7b 00 00 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |.{..LoCkBaDbLoCk|
0101ef20 c9 7b 00 00 ca 7b 00 00 cb 7b 00 00 cc 7b 00 00 |.{...{...{...{..|
0101ef30 cd 7b 00 00 ce 7b 00 00 cf 7b 00 00 d0 7b 00 00 |.{...{...{...{..|
0101ef40 d1 7b 00 00 d2 7b 00 00 d3 7b 00 00 d4 7b 00 00 |.{...{...{...{..|
其余的行看起来就像正常的磁盘数据,奇怪的是,尽管声称至少前几千个块都已成功读取,但第一行却hexdump
显示坏块。safecopy