So recently we've had a dying hard drive that we tried to copy all the data from using safecopy. The documentation as well as any guides I could find specified that safecopy's output has to be an image file. The command processed, but only yielded XXX as output, indicating unsuccessful reads for hundreds and thousands of blocks. Evidently that can't be correct since the drive was still mountable and most files were readable. Next I retried, specifying an HDD partition (/dev/sdb2) as the output, as someone suggested (I can't find the thread anymore, that was over a week ago). The command ran, outputting successful reads, finishing in the estimated time of over 5 days.
Now the drive has all the recovered data on it, but the partition has become unreadable. We can't repeat the recovery, as the damaged drive died soon afterwards (head crash, and a quite violent one at that) and we somehow have to get the data from the other HDD, which is definitely there since the command completed and wrote over the partition. Is it possible to retrieve it somehow? I was thinking if the intended target was an .img file, then copying the raw data from the device file to an .img with dd might give us the "intended result" that the command should have gotten us to begin with (that being having safecopy's output in the form of an .img file and not on a device), but dd froze after a few percent into the operation, which did not resume even after several hours.
The exact copy and output was lost due to running on a volatile system, but based on the devices and parameters I remember it must have been sudo safecopy --stage1 -b 4096 -R 2 /dev/sda2 /dev/sdb2, i.e. doing a stage 1 copy with added double retries from /dev/sda2 (broken) to dev/sdb2 (backup), both having a block size of 4096 bytes. The output yielded mostly ... as far as I could see, indicating successful block reads. The output ended with safecopy informing me that it concluded successfully, writing ~3TB of data.
sudo file -s /dev/sdb2 only yields the error message /dev/sdb2: ASCII text, with very long lines, with no line terminators, retrying with hexdump -C /dev/sdb2 gives a bit more insight on what's on the device:
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 |.{...{...{...{..|
The remaining lines look like normal disk data, what is odd is that the first lines of hexdump show bad blocks despite safecopy claiming that at least the first few thousand blocks were all read successfully.
