Hello,

I have an hdd with bad sectors. I need to copy some file before the disk has failed.

I tried copying one of the partition with gddrescue but the speed is less than 100B/s. With this speed I will need months to do that. I need around 20Gb, the disk capacity is 80Gb. I ran gddrescue in Ubuntu. The partitions of the failing device are ntfs.

Any help with rescuing the data?
Thanks

If the drive just has bad sectors and no other issue, you could try running Spinrite or HDD Regenerator on it to get it to a recoverable or usable state.

Also, if you want to quickly learn which regions of the drive are bad, use MHDD to do a scan and save the scan to log.
Anyone feel free to correct me if I'm wrong, this is based purely on my previous experiences.

Hi,

I am not sure actually if the bad sectors are the only problem. According to the Disk Utility in Ubuntu:
SMART status: Disk has few bad sectors.
Self Assessment: Passed
Self Tests: Completed OK
Bad Sectors: 1022

Reallocated Sector Count is with 'Warning'
Current Pending Sector Count is with 'Warning'
All the others are either 'Good' or 'N/A'

My current target is rescuing the data, not making the hdd work.

Additionally, I can mount the partitions and even see the folders inside. I just cannot copy them.

How can I determine if the hdd have some other problem and should I?

You just answered your last question "How can I determine if the hdd have some other problem and should I?" :
Reallocated Sector Count is with 'Warning'
Current Pending Sector Count is with 'Warning'
All the others are either 'Good' or 'N/A'

To be able to copy data from the drive, you need the drive to work, even for a little while. Hence you need to run one of the utilities that I mentioned above.

But before you do that, install HDD Sentinel. If the drive has at least 1% Health, you should be able to get most if not all of your data back. If the drive's health is 0% I recommend that you DO NOT RUN Spinrite or HDD Regenerator on it, but instead try this :

If I were you I would boot into Hiren's Boot CD either via CD or USB, run Get Data Back NTFS on the drive with the option to ignore read errors.

Then, using Get Data Back NTFS I would copy whatever I can from the drive to the other drive.

edit : your drive or should I say "data" right now is in a very fragile state. Do not run any more utilities that stress the drive, like the Long Self Test.

I used Ashampoo HDD control, it reported 99% health (but it was before I tried to copy with ddrescue).

I won't run any more utilities that stress the drive.

I've used before Get Data Back but for accidentally deleted files. I previously thought linux tools like ddrescue, etc, would be better at this.

I agree that the data is very fragile. That's why first I wanted to clone the drive. And after that to try to pull the files. It's pointed as a good practise.

Or probably I should try with different tools? I am confused.

As I said above, if the drive's health good, you can try Get Data Back NTFS. I recommended this because it's usually fast and if it detects any error what-so-ever it gives you the option to ignore it and just go on. If you know of other cloning/copying utilities that have the option of skipping errors, go with those.

Thank you very much, UzY3L.

I will do some more research and after that I will try with Get Data Back. I just want to make sure I won't make thinks worse trying to do it.

Meanwhile, I will appreciate some more ideas about what will be the best tool to make an image of the disk.

Your best bet is to use ddrescue and get an image and work from the image if you can't get a complete image then none of the other tools are going to work well with the drive in its current condition and you need to seek a pro with pro imaging tools to get the data recovered.

Ddrescue starts great but after a while it slows down - the speed is from 30B/s to 30kB/s. I'm not sure if that's a good behaviour - I could't find such info anywhere. Till now I have copied less than 1Gb. I already stopped it btw.

I ran ddrescue with the --no-split option, it's not complaining, just generating errors.

One more thing - I have some doubts about how to specify the 'outfile' and 'logfile' - by /dev/something or /media/something. I used the mount point. But in different sites and forums they do it different ways. It is clearly stated that the 'infile' should be /dev/something but not about the others.

I was advised to configure ddrescue to run in some way no to try a lot of times with the bad sectors. As I read the man page, the --no-split option should do something like this... I'm not sure.

Maybe this tool will be easier for you: http://www.datarescue.com/photorescue/v3/drdd.htm and yes the drive will slow down when it hits bad sectors and speed up on good ones or you may have a weak head and its going to run slow for the entire clone sometimes it does. A pro image tool may be needed in the end

I just tried again with ddrescue, the same results.

Probably with try with DataRescue DD next.

The fact that a HW imager cost thousands of $ and these so-called "tools" are free and nobody of us professionals use them on failing drives should mean something...

IF the disk is already so slow either heads are degraded and continue degradating or there is also something else that is firmware related. I would (with the appropriate tools) check and tweak the firmware for what is possible (= extract data with its heads) , unfortunately this is not an option.

Final note : sooner or later the drive will fail completely during these "free stuff" attempts.

@karamel4e,

I agree with the comments you've had so far. I'll just point out a couple of things...


I know a couple of possible reasons for this - problems reading the source drive is one obvious one, but there are other possibilities. In recent versions of ddrescue, you can force ddrescue to abandon slow-reading areas and skip ahead, but that only helps if later areas are easier to read. In future, please give your full ddrescue command line, if you want people to consider a detailed response.


If you're referring to error messages, then ddrescue doesn't "complain" that way for most errors (i.e. after it has successfully started). You need to check your OS error logging, for more details about what is causing the OS to report (probably read) errors to ddrescue. Without those specific error messages then, again, a detailed response is impossible.


The logfile will (almost) always be a file on a mounted filesystem. The choice of outfile depends on exactly what you are trying to do - that's why you're seeing variations across different examples.

You are taking risks by a DIY approach, but if the value of the data to you is less than the cost of professional assistance, and if you are prepared for the possibility that your attempts might make the situation worse (or even totally unrecoverable), then it's up to you to decide whether to take those risks or not.

P.S. Before following the earlier suggestion to run Spinrite or HDD Regenerator, I strongly suggest that you search the forum for prevous discussions on this subject - hint: You won't find the professionals recommending those utilities, after they've seen drives where those have been run.

@Vulcan

sorry about not providing the exact command I've used, nobody ever asked. So here it is:

sudo ddrescue --no-split /dev/sdb5 /media/0E9A45C49A45A8D3/image /media/0E9A45C49A45A8D3/logfile

where /dev/sdb5 is the partition on the failing device
/media/0E9A45C49A45A8D3/image is the mount point for a different hdd connected thru USB - I'd like to have the image there
I can provide the generated logfile also if needed.

After that I ran the same but with the -R option - it is supposed to copy the partition from the end to the beginning, am I right? (here I used another image and logfile, this means I have two different now).

About the errors, that's something like what I had ():
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued: 0 B, errsize: 0 B, errors: 0
Current status
rescued: 69792 MB, errsize: 29000 B, current rate: 181B/s
ipos: 69792 MB, errors: 1000, average rate: 184 B/s
opos: 69792 MB, time from last successful read: 0 s
Copying non-tried blocks...

About specifying 'outfile', 'logfile', I have another hdd which I decided to use to copy the data there. It has 2 partitions, I'd like to use the second one. I can make an image or use the whole partition, I don't care which one, if that's what you mean by 'what I am trying to do'.

I know the risks with a DIY attempts. I will take them. The data is important but it's not worth is in THIS case. I totally understand that I can brick the device.

And finally, I am not planning on doing anything else than making a copy of the drive for now.

Thank you

Update: I can provide more info if needed.

Thanks for the info.


No need to be sorry - just remember that we don't have a camera above your PC, so we don't know what you are doing. Therefore you have to explain everything, otherwise if we guess wrongly about what you have done, then you may get wrong advice, and then you may lose your data (unnecessarily) as a result, and/or we may get frustrated about wasting our time, when we find we have guessed wrongly. I hope that helps to explain things a little more, from the viewpoint of the readers.


What filesystem type is /media/0E9A45C49A45A8D3? (NTFS, ext[3|4], something else?) Some Linux NTFS implementations become slower when writing, as filesize increases, hence my question. I'm wondering if that issue is related to your your slow throughput, or whether it is as simple as just the source disk is slow at reading due to internal error recovery (which is very likely, but I wanted to check rather than assume).


Going to that level is probably more free support that I will offer remotely - I can only invest a limited time. However I'll remember your offer...


Correct - although I didn't see you mention the result of this attempt. Was the reverse clone attempt any faster than the slow speed you were seeing when going forwards, at around 69GB?


No!! The whole point about ddrescue and similar tools, is that you run them many times, using different parameters if needed, with the same output and log files. The point about using a common log file each time, is that subsequent runs of ddrescue only attempt to read parts which have not yet been successfully read. Think of it as "filling in the gaps" in your output file.

In your case, there may be no overlap between your "forwards" and "backwards" recovery runs, but now you need to merge the two image (output) files and two log files (or abandon one set, along with whatever data it contained - not a decision to be rushed). So unfortunately you've increased created a new challenge, in addition to your original one.

These files can be merged by someone with the necessary skills, but I'm not going to go into that now.


That's interesting, thanks, although I specifically said you need to review the errors being logged by the OS, if your previous question was asking why ddrescue wasn't "complaining" as you put it. You'll need to get Linux support elsewhere, as the location of the relevant log file typically depends on which specific Linux distro you're using, and whether it's a liveCD/DVD/USB or a hard disk installation. Personally I find that monitoring the type and timing of errors logged by the OS, helps me to understand what is happening in the ddrescue screen display that you provided.

Anyway, what your ddrescue display snapshot seems to show, is that the recovery was still making (very slow) progress since "time from last successful read: 0 s", with just 29kB of unreadable data so far, of the almost 70GB that was read by that point. I have seen stories from ddrescue users of them leaving the process for several weeks in extreme cases. Some clones are (eventually) mostly successful; some clones fail as the "problem disk" dies before the end of the process. As always, YMMV.

Since your "problem disk" is only 80GB, and the ddrescue screenshot shows 69GB read so far, then you're down to the last 10GB-ish, aren't you?


In the context of your previous question, which I was trying to answer but didn't know your chosen ddrescue command or what your objective was, then you have now explained why you need to use a mountpoint for a regular file, if you have decided to use that for your image file (outfile). That approach has advantages & disadvantages, but I've run out of time now to explain further.

Just briefly, you may want to investigate the ddrescue "-a" option (e.g. set a minimum speed of 10000 bytes/sec), to skip slow sections of the remaining unread section of the disk on the first pass, but read the warnings in the ddrescue online manual on that point. That might help you to clone some of the remaining 10GB of disk space before the disk dies, if there are any "fast" areas in that section.

After you've attempted to read the whole disk at least one without retries, then you can allow ddrescue to perform some extra retries, and/or use direct access etc. to see if any more sectors can be read.

Good luck! At least you seem to have almost 70GB of data recovered so far.

All of you have been very helpful.

Unfortunately, I don't have access to the hdd right now. I will have to just pause all the attempts and start again as soon as I got home.

So for now I will leave the topic open.