Looking for help recovering data from a drive

[gte]

Hi,

I have a drive that has unreadable sectors after a drop. It's a Fujitsu sata 160gb laptop drive.

Using linux, I am able to browse the file structure. Is there a utility that I can use to copy data from one drive to the other? And even better if it will ignore errors when copying?

[labtech]

Be careful how long you keep on powering the drive on. What you have described are signs that drive will not last much longer.

Although not recommended in these circumstances, you can search dd_rescue.

[gte]

Hi labtech,

Thanks for the reply, I found this post
http://www.myfixlog.com/fix.php?fid=21
and I am using ddrescue inside of parted magic and I'll try to use p2 to mount the image.

So far I have 6gb out of 40 ... it calculated to run for 5.84 hours total. The only problem is that I named it sda4.bak.dd instead of sda4.img, hopefully not an issue?

[labtech]

You can try renaming it ____________.img after completion.

[gte]

Ok thanks, hopefully that works!

[Vulcan]

@gte - that suggestion from labtech will work. The output image file from ddrescue is just a file, like any other file, and can be renamed, deleted etc. etc.

[Edited to add: I also agree with labtech about the risks of possible drive degradation with use, after this type of damage.]

[gte]

Thank you for the warnings about the risks ... I was expecting it to make a 40gb image, but after thinking about what I have read, this may be a bit for bit copy and it may make the image the same size as the actual drive including all of the free space?

Will the image be 40gb or 160gb (the drive size)?

[Vulcan]

Will the image be 40gb or 160gb (the drive size)?

That depends exactly what command you are using - but ddrescue knows nothing about used vs. free space.

You will need to supply the exact ddrescue command line that you are using, and explain which drives are which /dev links, if you want a better answer - remember that I (and other readers) can't see your machine, so we have no idea what commands you are actually typing on your keyboard

The answer to your question is likely to be 160GB, but it all depends on your ddrescue command line, and might depend on your drive partitioning too, depending on exactly what you typed...

[gte]

That's a great point Vulcan!

From memory, I believe I ran this command

ddrescue /dev/sda1 /media/sdb3/backup.bak.hdd conv=noerror,sync


sda4 is the 160gb laptop drive (no partitions on this drive)

sdb3 is the 300gb desktop drive, I believe it has a 40mb partition, a 10gb partition and the remaining ~ 290gb as sdb3

[Vulcan]

From memory, I believe I ran this command

Why can't you see the exact command on the screen, or in the shell command history (open a shell and press the up arrow), instead of guessing from memory?

ddrescue /dev/sda1 /media/sdb3/backup.bak.hdd conv=noerror,sync

sda4 is the 160gb laptop drive (no partitions on this drive)

sdb3 is the 300gb desktop drive, I believe it has a 40mb partition, a 10gb partition and the remaining ~ 290gb as sdb3

There are several things wrong with what you have written

Did you mean to say that sda or sda1 (not sda4) is the 160GB laptop drive?

Also, every hard disk has at least 1 partition (if it uses filesystems, which applies to 99% of PC systems), so I don't believe your comment that there are "no partitions on this drive". Perhaps you mean that there was 1 partition which used the whole of the disk? In which case that will usually be sda1 - so I think your mention of sda4 is probably wrong.

If you chose /dev/sda1 as the first parameter to ddrescue, then that means you are not copying the MBR. You can copy it later, but you need to be aware of exactly what you are doing.

Also, ddrescue uses different command line parameters to dd - AFAIK the conv parameter is not used by ddrescue (I'd need to check the source code to be sure), but it certainly isn't documented as a parameter.

http://www.gnu.org/software/ddrescue/ma ... anual.html

Your ddrescue command line above does not mention using a logfile - that's not good, as it prevents you from using the multi-pass recovery feature of ddrescue.

So in summary, there are several problems with your previous answer but I'll guess that the answer to your original question about the possible size of /media/sdb3/backup.bak.hdd is "up to 160GB". However, if your ddrescue line "from memory" is correct, then by not using a logfile, you have reduced the chances of full recovery, unless you are very lucky that everything is readable in the first pass of ddrescue.

[gte]

The machine is a few miles away, which is why I could not check the command verbatim.

Should I cancel the command (if it is still running) and add a switch for a log file? You were correct about the sda1/sda4 typo.

I will check again and provide more info about the command, I will have to write it down and bring it back to this machine as I can't post from the master machine when it is booted to parted magic, I apologize for the confusion that causes. I'm pretty sure the MBR is hosed or at least it was from a Windows perspective, is there a way I can confirm it is accessible?

[Vulcan]

Thanks for explaining the situation - it's just difficult to give advice, without accurate information

Should I cancel the command (if it is still running)

There is no "right answer", because it all depends on whether the disk drive is about to fail, or not - and we don't know that. There are risks and benefits to different approaches, and it's your data and your choice to do DIY, so it has to be your decision.

If it was me, I would allow this ddrescue pass to run through to completion now, just in case the disk does fail soon. If some parts of the source disk could not be read on this "pass", then make sure you're using the latest version of ddrescue and try to create a logfile using the "--generate-logfile" option, as explained on the webpage I linked before. The resulting logfile may not be as good as if one had been used originally, but it's better than not having one at all, if you need to use multiple passes of ddrescue.

I'm pretty sure the MBR is hosed or at least it was from a Windows perspective, is there a way I can confirm it is accessible?

The original MBR cannot be hosed, if your ddrescue command line really used /dev/sda1 as the source parameter - that's because Linux has to read the MBR to find the size & location of partition 1 on /dev/sda, in order to access /dev/sda1

You may not need the MBR - it all depends how you plan to use the ddrescue output file.

[gte]

Hi Vulcan,

Well section 9 is definitely me, I was so upset and panicked about losing my data, I started the drive copy without reading everything.

The drive copy should complete in a few hours, so when I get home from work I will run the following command

Code:

ddrescue --generate-logfile /dev/sda1 /media/sdb3/backup.bak.hdd /media/sdb3/logfile.txt

from

ddrescue /dev/sda1 /media/sdb3/backup.bak.hdd conv=noerror,sync

I will try and run the correct command (below) for a second image backup creation as well, and that is going to be on a different computer this time with more hard drive space. I did not know ddrescue has so many options so it looks like I had a lot of reading to do about it.

ddrescue inpartition outpartition logfile


Do you recommend any switches to consider before I reread this document a few times to become comfortable with it? I want to use the output file to be able to browse my data and restore it to the new drive once I install and image it. Will I need the MBR? I will be happy if I can just browse through the image and extract certain data to its new location.

Thank you for the help Vulcan

Thanks for explaining the situation - it's just difficult to give advice, without accurate information

Should I cancel the command (if it is still running)

There is no "right answer", because it all depends on whether the disk drive is about to fail, or not - and we don't know that. There are risks and benefits to different approaches, and it's your data and your choice to do DIY, so it has to be your decision.

If it was me, I would allow this ddrescue pass to run through to completion now, just in case the disk does fail soon. If some parts of the source disk could not be read on this "pass", then make sure you're using the latest version of ddrescue and try to create a logfile using the "--generate-logfile" option, as explained on the webpage I linked before. The resulting logfile may not be as good as if one had been used originally, but it's better than not having one at all, if you need to use multiple passes of ddrescue.

The original MBR cannot be hosed, if your ddrescue command line really used /dev/sda1 as the source parameter - that's because Linux has to read the MBR to find the size & location of partition 1 on /dev/sda, in order to access /dev/sda1

You may not need the MBR - it all depends how you plan to use the ddrescue output file.

[gte]

Well, it looks like I have to kill this, it is at 205gb and counting, and I'm running out of freespace on this machine.

The drive size is only 160gb, I don't understand?


It looks like the drive was /media/sda4, and there is no sda0 - sda3?

[gte]

Now that I can see the exact command I typed, it was

dd if=/media/sda4 of=/media/sdb3/bradtemp/sda4.bak.dd conv=noerror,sync

[gte]

The drive is clicking, but the rescued: MB: is slowly increasing a mb at a time ... does that mean it is still working correctly?

It almost sounds like the head is stuck in a loop?

[Vulcan]

I see several questions since I last had time to logon, but again, I only have a short time now so some brief answers:

ddrescue inpartition outpartition logfile

That is not what you are (or probably mean to be) doing - in your case, your output parameter is a file, not a partition. The input file in your case can be an unmounted partition (e.g. /dev/sda1) or the whole drive including MBR (e.g. /dev/sda) - see comments below.

Will I need the MBR?

It'll help if you copy the original one, although it can be (approximately) reconstructed by experts with some effort (or, in some cases, using testdisk or similar). If you reach the stage when ddrescue has stopped running, then before whatever else you're going to do, run this to grab a copy of the MBR into the named file, for later use:

Code:

dd if=/dev/sda of=/media/sdb3/bradtemp/sda.mbr bs=512 count=1

The MBR is not needed for just browsing the filesystem (a copy of a partition can be mounted without needing the MBR), but it'll help to have the MBR if you're going to try to put the image back onto a disk later.

Now that I can see the exact command I typed, it was

dd if=/media/sda4 of=/media/sdb3/bradtemp/sda4.bak.dd conv=noerror,sync

That broke another of the rules of using ddrescue or any cloning - the source (first parameter), was a mounted filesystem. You're also going back to mentioning sda4 when I thought you'd already cleared up that you had previously meant sda1. This is very confusing

Is the partition mounted read/write or read-only onto /media/sda4? If you don't know the answer, open another shell (even if ddrescue is still running), enter "mount" and you'll see the mount options currently being used - look at the line which mentions that mount point. If it is mounted read-only (ro), then you should "get away with" that command line mistake. If it is mounted read/write (rw), then you've broken a ddrescue (and any cloning) golden rule, and the result might be...:

IMPORTANT! Never try to rescue a r/w mounted partition. The resulting copy may be useless.

Regarding the clicking drive - no surprise there, considering your reported problem. If the number of MB rescued is increasing, then you're still successfully copying data - but if the number of errors is also increasing, then that shows there are some areas you're not reading at the moment, and which (since you've chosen DIY) may need extra effort with different ddrescue options and also need a ddrescue logfile, to have a chance of recovering. (Or, if you have changed your mind about the importance of the data and are now prepared to pay for the services of a DR company, then before the drive dies completely, you would need to give them a chance).

As I said at the beginning, by choosing to do DIY on a damaged drive like this one, you are taking risks and the drive could fail at any time. Good luck!

[gte]

Hi Vulcan,

Thank you again for all of your help. It currently is sda4, I don't know why but two different machines have seen it that way.

I can check the mount command when I get home from work, I did take this picture on the first computer I tried this on, however to try and make more sense of things

[gte]

Vulcan, I tried to post a cell phone picture and the first time it did not post, the second attempt is (I believe) waiting for moderator approval, probably because it has a picture in the post and because of my low post count.

I've noticed that they are listed there as /media/sda_, but in some cases can also be referenced as /dev/sda_ ? I'm sorry about the confusing names, I will take another picture of the results from fdisk -l if that will help. I should have taken pictures in the first place, and had I been less panicked I would have. I do not know how to tell if they are mounted as read/write, but the bad drive has not been mounted (through the GUI) at all when I run these commands.

[Vulcan]

probably because it has a picture in the post and because of my low post count.

Yes, that will be the reason. We should see the photo when the post is approved by the mods...

Regarding device names - I don't attempt to teach Linux via web forum, and with due respect, you probably need to have done more research & background reading before using ddrescue due to the risks involved, but in short:

I've noticed that they are listed there as /media/sda_

That is only true when a filesystem has been mounted (whether manually by you, or automatically by your Linux distro). Even after a filesystem within a partition has been mounted, you don't have to (and, for this type of case, you should not) access the source partition through that mount point.

but in some cases can also be referenced as /dev/sda_

That is the raw block device name, and this exists whether or not the filesystem on that device is mounted (assuming that the underlying device itself [in this case the disk drive] is recognised by the OS, and depending on whether the MBR is readable, for reading of raw partitions).

I'm sorry about the confusing names

The problem is that giving incorrect details then wastes time, trying to guess what the correct details really are, or undoing previous suggestions, and I don't have an unlimited amount of time to give

I've also realised that something you said before, appears to also be wrong. You said that:

Now that I can see the exact command I typed, it was

dd if=/media/sda4 of=/media/sdb3/bradtemp/sda4.bak.dd conv=noerror,sync

and also said that:

rescued: MB: is slowly increasing a mb at a time

But you won't see any mention of "rescued" MB from dd?! So what is correct information, and what isn't?

At this point, I have to stop spending more time on this, as I'm wasting my time due to the inconsistencies in the information you're supplying - I have now have no idea what is true and what is mistaken information, and I have run out of time to guess.

When you can give accurate information about the command(s) you've used, then you might get more suggestions here. Doing some background reading of ddrescue tutorials may also help you to clarify how to use it. Good luck!