hi, all,
i am using knoppix 8.2 and using the ddrescue to run data recovery. however, after running for a day, it got stucked at 97%. i manually invoke to stop it and now i can't see the output of ddrescue on my target disk. could it be hidden or anything else that i have missed?

this is the log:

# Mapfile. Created by GNU ddrescue version 1.22
# Command line: ddrescue -f -R /dev/sdc /dev/sdd /home/knoppix/Desktop/log2.log
# Start time: 2019-04-05 16:16:22
# Current time: 2019-04-06 17:07:39
# Copying non-tried blocks... Pass 1 (backwards)
# current_pos current_status current_pass
0xC60390000 ? 1
# pos size status
0x00000000 0xC60380000 ?
0xC60380000 0xDC7E980000 +

Sounds like this is your data. Not sure if this actually copied the data from your patient to target and you'd need to run another Dr program to see if you actually have data on the drive. R-Studios would be a good one to start with. Scan the target disk and see what data was copied. If nothing was copied then you have done something wrong. You might want to check here on the forum for the free tool the forum owner has written that is an excellent tool for cloning hard drives.

_________________
Iorana Haraharaini

I don’t use ddrescue, but from looking at that log it appears that it’s been cloning backwards.

So if you say it’s cloned 97% then you’ll be missing a good proportion of the file tables and such in the first 3%.

If the patient drive is still alive, then try again forwards. It could be that there is a bad patch of media at ~3%

Once you’ve tried that, then run some DR software on the clone as Ann says.

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

Indeed the -R switch means that all operations are done in reverse direction, so pass 1 which is usually done in the forward direction is done backwards. It can be beneficial in some circumstances, but it is much slower. (Typically I get at least 50MB/s on good areas of a failing drives in forward direction, but less than 5MB/s in reverse direction.)

And since a whole drive was selected as target, then all the data from the source has been (normally) written directly to that drive, not to an image file on that drive. (Let's hope that this is what you wanted, and you didn't overwrite files that you wanted to keep on the target drive.)

And since about 53GB are missing at the beginning, indeed, as it's been said, most filesystem structures are missing. At this point only a “raw” file recovery may be provide good results (but it means losing the original directory tree structure and all the files' attributes / timestamps, plus if files were heavily fragmented, most of the recovered files will be truncated thus unreadable). With a NTFS partition, the best course of action is to recover the MFT first, using ddru_ntfsbitmap from ddr_utilities. It also allows to copy only the allocated clusters, which can save a lot of time and unnecessary strain on a drive which has a low amount of currently allocated data (even if it has a lot of old deleted data all over, this will be ignored based on the $Bitmap file) – provided that at least the $Bitmap is perfectly readable, if it doesn't extract it quickly (meaning that there are bad sectors occupied by the $Bitmap), don't insist and do a regular full recovery, as it would do more harm than good, bad areas should be dealt with last, when most of the good areas have been secured.
In this situation, since most of the good data has been secured already, try resuming from the beginning of the drive in the forward direction, with “-i 0” and without “-R”. It will bypass (for now) what appears to be a bad area around the 53.15GB mark, and hopefully secure the area containing the filesystem structures, making the outcome of the recovery much better, even if it turns out that there's an unreadable chunk beyond 50GB for instance.
Then when all is finished, you can use either ddru_ntfsfindbad (for a NTFS partition) or ddru_findbad (for any other kind of partition), both also included in ddr_utilities, to get a list of files corrupted because of unreadable sectors. And then you can consider making a small donation to the author of those marvelous little tools (“maximus” on this forum, also author of HDDSuperClone), even though they're no longer supported !

Also, when using a live system, it's not a good idea to put the log file in a /home/knoppix/... directory, which is “volatile” and will vanish if there's a power loss or any other issue requiring a reboot. Better put it on a USB flash drive, memory card, or any other physical storage device (preferably with nothing valuable and non-backed-up on it, normally it's harmless but typing a wrong command can happen, especially when you're inexperienced and anxious about recovering your own data).