ddrescue
 

I have a drive which is partially working.Few files were working fine I copied them to another drive using ubuntu. But When I copied other files ,ubuntu gave me I/O errror.

I used ddrescue .Its currently running for two days but at very low speed (It's in B/s).

Source drive is exfat based.
Destination drive is ntfs based.

Both drives are of same comapny "WD" ,same size 1TB.

I gave the command : I even tried to run it in reverse order but still speed is too low.It will take forever to complete.

Am I doing something wrong?
Should I used another tool for backing up the files ,I mean other than DDRESCUE?
Should I improvise ddrescue command by adding some options?
Should I used another linux distribution for backing up files fastly?

"-r 3" will slow it down more on bad sectors - maybe leave it out. If the drive has a lot of errors, it will still be slow - wait for it to finish. Can take days.

No I have started without any advice from experts.

I will try to do -r 1

What are you tring to achive? If you ddrescue a partition to an image on another drive the exact same size it's likely that the process will interrupt at 99something percent due to few disk space.
To just rescue files i can recommend PhotoRec, a tool from the package 'testdisk'. It will deliver all files it can rescue sorted by type. Some broken files might only be available in fragments but the data will be there.

Thanks a lot for saving my future hard work.
I visited the website and tried to install but error occurred

Error when getting information for file “/home/jordan/Desktop/testdisk-7.2-WIP/INSTALL”: No such file or directory

how to install these testdisk-7.2-WIP.linux26.tar.bz2 file after extraction?
There is no Install file.

I read in the website that It is also available for windows, It will be easy to install .exe files, but will it be good idea?Will it be reliable and fast as compared to Ubuntu?

if using PhotoRec inside windows is not a good idea then how to install it in ubuntu?
I mean how to install testdisk-7.2-WIP.linux26.tar.bz2 file after extraction? I searched for this issue, most of the time they tell me use \configure then make and then sudo make install, but no such files are in the pacakage?

I simply want my files from damaging drive to be moved to another safe drive.That's all.

As I said earlier I was having I/O error while moving data ,So I used ddrescue to move the data that can be moved with some help.

According to you, I should use photorec instead of ddrescue .Will photorec be able to move my files from damaging drive to safe drive?

I don't think you have to build the package using 'make'. You said you were running ubuntu, right? Try searching for 'testdisk' using the package management GUI, if i remember correctly ubuntu uses synaptic package manager. Or just use as root from terminal

Thanks,installation is complete and I have also started the photorec .

But Will photorec be able to recover the file that already exists?

I learned that photorec is for recovering files that has already been deleted.Will it work in my case where files are not deleted ,i just need to move files from one drive to another?

Though I have started photorec, It is showing 4912hours remaining.0 files found yet.

I have a doubt I choose the media to recover,then it asked me to choose partition ,I choose HPFS-NTFS then it asked me "To recover lost files, PhotoRec needs to know the filesystem type where the
file were stored:"
1) [ext2/ext3] ext2/ext3/ext4 file system
2) [other] FAT/NTFS/HFS+/ReiserFS/...

I choose 2 [other], beacuse my source drive was formatted in exFat format. DID I CHOOSE CORRECT OPTION?

That's what photorec is basically intended to do.

Btw i just realized that you can run photorec directly from the un-tar'd package:
if you don't want to use a package manager.

Photorec etal is aimed at a different situation - basically where files or partitions have been deleted, but haven't (yet) been over-written and are thus still retrievable by matching a template.
Where there is physical media failure as here, they are no more useful than cp or the GUI equivalents. And typically no faster than ddrescue, even where applicable.

Does this mean I should Stop right here?
Should I stop photorec and move back to ddrescue?

check syg00, Should I stop photorec?

Sorry, my bad it seems photorec needs you to be root to run.
(so be careful with the steps you take)

It will take at least as long as dd and like said it will deliver all recognized files sorted by type. So you'll get a drectory with subfolders "TXT", "JPG", "DOC" etc containing the rescued files.

If in doubt stop the process. With both drives are attatched to the system, what's the output of 'df -ah'?

As a general rule I always advocate that a disk that is suspected of being faulty should be stressed as little as possible. Take an image and work on an image of that image. If things mess up, take another image of the first image and try again.
ddrescue with a logfile as you are doing is the best way to get an image with least stress if the disk is failing. You can then try any of the forensic tools without worry of making the origin situation worse.

That taken into consideration it would be good advice to use ddrescue the faulty 1TB drive to the healthy one and use photorec on the latter.
What OS are you running photorec in? As said above if in doubt stop the process.
Here are good step-by-step instructions on how to work with photorec.

I second this advice.

Regardless of whichever method you try, taking an image of the drive is a best, first option, which can be performed with ddrescue.

This seems as if the recovery process is confusing to you, gkd.

Photorec will only recover files which are no longer active, as in deleted files, or fragments of files it can find that were overwritten and thus made not to be current valid files.

If the drive is not performing well so that you cannot access files, making an image of it will allow you to work with that image and possibly recover files which are corrupted by a bad drive.

It's hard to say. The files you were able to copy, those should be all set. If you're able to successfully make an image, then I'd work with that.

At some point it may turn into diminishing returns. Meaning the time, effort, and space exerted to recover files, and maybe partially recover files, not all and not all in entirety, may not be worth your while, you'll have to assess this.

I would re-reference syg00's signature here:And also reference a comment from the site guidelines:I recommend assessing the recommendations, prior to proceeding with any future commands.

Note that photorec does not recover file names. It totally ignores the filesystem and goes after the underlying data. Blocks of data that have a recognizable format are stored with newly generated names.

For the initial run of ddrescue, leave the "-r" (--retry-passes) option at its default of 0. Once all the easily read data has been recovered, you can rerun (using the same log file) with a non-zero value to attempt rereads of previously detected bad sectors.

Sometimes, ddrescue will run much faster if you use the "-d" (--idirect) option. This helps by preventing the kernel from doing its own retries of bad reads. Note that you have to set the sector-size correctly if the drive does not have 512-byte physical sectors.

As has been said an image then working with the image is best. However, dd (and ddrescue) will always try to copy every byte of the original disk and if you are not writing to a partition with more space than the original disk then you will likely run out of room and have to start over, with totally wasted time and stress on the failing drive.

It was recommended to use photorec, and the web site where that is hosted gives fairly good directions in usage. Photorec has a major advantage over both dd and ddrescue in the size of the output. It only saves what it identifies as file data, instead of the probably many MB or GB of null bytes on the disk.

The thing you have to remember with any rescue tool is that they all have to read bit for bit the content of the source and either copy it (ddrescue or dd) or put it together as a file (photorec). All of that reading of a TB of disk space can take a long time. Every time that is interrupted it adds to the time needed.

One thing that might improve the speed of dd or ddrescue would be to use the block size option and set it to a value significantly larger than the default 512 bytes. I routinely use bs=32M or bs=64M, sometimes even larger depending on the free memory on the system.

I have a drive "wd my passport" 1tb. I am connecting it on Ubuntu 20LTS.

I am not able to open any data, not even able to copy or move any data. While Coying ubuntu gives error of I/O.

But I am able to delete few files and folder which is not necessary.

Why is so?

I even tried ddrescue to recover ,but it's very slow, too slow.I lost my patience and got recovered 1gb of data through ddrescue and then deleted the .img file also.

I even tried a powershell script in windows 10 , script was developed by davor josipovic.But copying ecah file separately is hard job and time taking.

I just want to know why deleting files is easy and accessing files hard? What can be the solution to get files fastest and easiest way possible

Deleting a file just requires access to the filesystem metadata. The file's actual data blocks are not accessed at all. Reading a file of course requires access to the data blocks.

Is this the same drive, or a different one?

What's incorrect about following advice from earlier in the thread about using ddrescue or photorec?

Assuming you added to a running Ubuntu machine and after it mounted, you got some errors, but then you deleted some files?

Is this about recovery, getting a drive to "just work", or what exactly?

Hard to make recommendations, first if data on a drive is critical and you don't know much about recovery techniques, there are vendors who can help, but yes they are costly. If you wish to explore trying things out yourself, all good, but you seem to be switching between Linux and Windows and trying some number of things. Those attempts seem pseudo random, in that they're learned attempts from your prior experiences, but they also appear to be not fully organized methods.

At this time, it's confusing what you wish to do or accomplish, the best advice I think stands from multiple persons, do not write to a drive you intend to try to recover (deleting files constitutes writing to a drive by the way), also, make an image of the drive and work with the image, or a copy of the image. Then use the programs cited to try to recover files from the disk image.

I'm not sure that I've seen you post any update where using one of these programs has yielded any recovered data, instead you've terminated the programs. I can say that for Photorec, you can examine the recovered archive directory and find incremental file fragments as they get recovered. You will be able to see some results while the recovery process is occurring.

Best of luck with your efforts.

So why should we waste our time helping ?. Goodbye.