Solved Best method/tool for cloning a failing HDD for Data Recovery?

jumanji said:

I just had a quick run-through with Trinity Rescue kit. It will perhaps be too much for a non-Linux user. That is my first impression.

So then, I have come to the best way to clone a failing HDD sector by sector atleast for now )

Tool: ddrescue Source: SystemRescueCD

1. Download the SystemRescueCD from Download - SystemRescueCd systemrescuecd-x86-4.2.0.iso 380MB and create a bootable pendrive with that ISO using Rufus Rufus - Create bootable USB drives the easy way

2. Boot your computer with that pen drive with your source disk (your failing disk) and a destination disk (formatted empty disk of capacity not less than that of your source disk) plugged in.

3.Against the command prompt type: fdisk -l [ENTER] This will list all your drives. Note the nomenclature of your source disk and destination disk.

4. Next against the command prompt type: ddrescue -r3 -n -S -v /dev/sdb /dev/sdc recovery.log [ENTER]

Note: Replace sdb and sdc with the correct device nomenclature of Source disk and Destination disk as obtained in step 3.

5. Sit back and relax. The cloning process may take days depending upon how bad your Source disk is. If your data is important patience is the key and the wait worth it. The saving grace is you can stop the process any time with Ctrl -C and then restart. It will take the cue from the log file and start from where it left.

In the cloning process itself it will go through cloning all the good sectors first and then try to recover the bad sectors one by one trying it 3 times (r3 option) before giving up on it.

I have actually tried it cloning an 8GB pen drive with bootable Peppermint Linux ( that was created sometime back on a request from Golden to try it and report ) onto a 32GB freshly formatted pen drive. It took about half an hour. At the end of the cloning I was able to boot into Peppermint from that cloned drive which signified successful sector by sector cloning including the boot sector/s.

May be Anshad Edavana will be able to polish it and improve upon it as one who had actually tried it on a failing disk. ( As indicated already I had no failing disk.)

Click to expand...

Hey guys,

So, Im going to take a shot at this and had some questions:

1. is this still the best set of instructions, and command to use?

2. am i able to boot from the external hard drive that i make this image to, or some change needs to occur before i do that? (i.e. linux filesystem to windows filesystem conversion, or some other requirement)

3. after i make this image (assuming it completes), what exactly am i going to do with R-studio to recover the bad sectors?

4. do i need to format the external harddrive in a certain way/format before i begin this?

5. I would like to do this from a failing SSHD (hybrid), to a external HDD using a USB cable. Is it still the same set of instructions?

6. A little off topic but, if i leave the bad drive installed for now, in UEFI can i stop it from getting mounted on boot?

7. Another Off topic question, before the failing SSHD diagnostics i copied over a 60GB directory from a an old PC. within that directory there were various subdirectories not showing correct file names/paths. could this large/old directory somehow have caused or resulted from the SSHD to go bad?

Thanks!

ddrescue1111 said:

jumanji said:

I just had a quick run-through with Trinity Rescue kit. It will perhaps be too much for a non-Linux user. That is my first impression.

So then, I have come to the best way to clone a failing HDD sector by sector atleast for now )

Tool: ddrescue Source: SystemRescueCD

1. Download the SystemRescueCD from Download - SystemRescueCd systemrescuecd-x86-4.2.0.iso 380MB and create a bootable pendrive with that ISO using Rufus Rufus - Create bootable USB drives the easy way

2. Boot your computer with that pen drive with your source disk (your failing disk) and a destination disk (formatted empty disk of capacity not less than that of your source disk) plugged in.

3.Against the command prompt type: fdisk -l [ENTER] This will list all your drives. Note the nomenclature of your source disk and destination disk.

4. Next against the command prompt type: ddrescue -r3 -n -S -v /dev/sdb /dev/sdc recovery.log [ENTER]

Note: Replace sdb and sdc with the correct device nomenclature of Source disk and Destination disk as obtained in step 3.

5. Sit back and relax. The cloning process may take days depending upon how bad your Source disk is. If your data is important patience is the key and the wait worth it. The saving grace is you can stop the process any time with Ctrl -C and then restart. It will take the cue from the log file and start from where it left.

In the cloning process itself it will go through cloning all the good sectors first and then try to recover the bad sectors one by one trying it 3 times (r3 option) before giving up on it.

I have actually tried it cloning an 8GB pen drive with bootable Peppermint Linux ( that was created sometime back on a request from Golden to try it and report ) onto a 32GB freshly formatted pen drive. It took about half an hour. At the end of the cloning I was able to boot into Peppermint from that cloned drive which signified successful sector by sector cloning including the boot sector/s.

May be Anshad Edavana will be able to polish it and improve upon it as one who had actually tried it on a failing disk. ( As indicated already I had no failing disk.)

Click to expand...

Hey guys,

So, Im going to take a shot at this and had some questions:

1. is this still the best set of instructions, and command to use?

2. am i able to boot from the external hard drive that i make this image to, or some change needs to occur before i do that? (i.e. linux filesystem to windows filesystem conversion, or some other requirement)

3. after i make this image (assuming it completes), what exactly am i going to do with R-studio to recover the bad sectors?

4. do i need to format the external harddrive in a certain way/format before i begin this?

5. I would like to do this from a failing SSHD (hybrid), to a external HDD using a USB cable. Is it still the same set of instructions?

6. A little off topic but, if i leave the bad drive installed for now, in UEFI can i stop it from getting mounted on boot?

7. Another Off topic question, before the failing SSHD diagnostics i copied over a 60GB directory from a an old PC. within that directory there were various subdirectories not showing correct file names/paths. could this large/old directory somehow have caused or resulted from the SSHD to go bad?

Thanks!

Click to expand...

Is ddrescue not the best way to go about this anymore?

HDD Raw Copy

There is an awesome, free program from HDDGuru.com called HDD Raw Copy Tool. It runs from within Windows and will do a sector by sector copy, automatically skipping bad sectors. I have found it useful when a source disk is too badly corrupted for most conventional cloning programs to handle. This program also allows you to backup a whole drive or partition and restore from the image.

Hi mates, thank you a lot for such precious topic.
I would recoend anyone to *never* connect a highly daaged disk under Windows, this OS is pretty invasive and try to stress the HDD if it fails to read. I also have big suspect that it tris to write something on MFT as default behaviour, even if the disk painfully answer.. it couldn't be worst than this, but we know.. they will probably never care about it.
So all the utilities to recover under Windows could be pretty welcomed in case of softw corruption or deleted files/format, but only if the disk is healthy. For bad sectors avoid it.

I also agree that making a ISO would be the best solution, later there are softwares able to extract files from it, without worries that defective HDD getting worst and worst by time. I like GetDataBack.

QUESTION/HELP: (THANKS!)
I'm quite disoriented about the string to use with ddrescue, here I read different examples, and I dubt about the parameters to use. For example:
ddrescue -f -n /dev/hda /dev/hdb mapfile
ddrescue -d -f -r3 /dev/hda /dev/hdb mapfile
ddrescue -r3 /dev/hda2 /dev/hdb2 logfile

I need to produce an ISO file, readable by GetDataBack. I'd like also to have a log file and save it to the destination drive. 3 retries are good, what parameters should I use?

Kindly write me what lines to write, first I should know how the disk are mounted, then the ddrescue line.
SystermRescueCD is at version 4.9.2, I'll use that

Since unfortunately nobody helped here I got myself a chance.

Starting from SystermRescueCD 4.9.2 I typed following commands:
ntfs-3g /dev/sdc1 /mnt/windows/ (I mounted r/w the target hard drive)
ddrescue -d -n -f -r3 -y /dev/sdd /mnt/windows/iso.iso mapfile

The mapfile is written to the destination drive, because, I suppose, at propt I've selected /mnt/windows# instead of root#. This is better then have it in RAM disk, stored even if something can be wrong.

I discarded -n parameter (I'm not sure I did right) since I let the ddrescue analyze deeply the bad areas. I added -y cause I saw natevely program stores an amout of data (about 200MB) on RAM before writing them, during this period somehow the defective disk started "retrying" before reading again, making the rescue longer; with -y it writes what it reads, it goes slower (around 6MB/sec instead 25) but goes consecutively till the next bad area.
Anyway I noticed it stops after some MB, maybe the disk is recursively bad after some MB but it looks very strange, probably the software isn't much perfect.. or it's a problem of the USB SATA adapter, or it's a problem of overtemperature of defective HDD.. anyway I'm still scanning surface, I'll let you know

jumanji Anshad Edavana
Have to post my success story. essenbe pointed me to this thread.

Failing Samsung laptop drive (spinner) on a Dell N5010; 4% health, abundant read errors. Evidently DropBox had been installed and 176Gb of data downloaded several months ago (leaving 55GB free on a 320GB drive). Unbeknownst to the owner, DropBox had been thrashing the drive constantly for months. When the owner rang me, it was because the computer had gotten so slow, nothing could be done on it. I identified the DropBox issue, we uninstalled the program and deleted the 176GB of files from it. I checked the HDD health, and it was fine. The next day, upon booting, a Samsung window appeared on the desktop saying the hard drive was bad. I instructed him to shutdown, and collected the system the following day.

Crystal Disk Info showed read errors off the charts. Offline Macrium would image the drive, but with errors, and the 2 images I made could not be mounted to be read. So, in a last ditch effort to save precious photos, and years of family history research, I came to this thread, read it in its entirety and tried ddrescue.

I grabbed an extra rig, disconnected its internal HDD and connected the 320GB failing laptop drive in its place. Then I created the SystemRescueCD flash drive using Rufus and booted the system to it. Once it was ready I plugged in an empty 2TB USB external expansion drive, ran fdisk -l and identified my source/target. The recovery command I used was this:

(sda3 was the source Windows OS partition where all the personal files would be found.)

After seven hours, the program completed at 99% success.

I then took the external hard drive (target), hooked it up to my main rig and ran it through a paid edition of MiniTool Power Data Recovery. Pointing it to the user folder, I was able to recover just over 16GB of data, which I believe is just about what he had on there. After saving the recovered files to my rig, I opened a few pictures, documents, text files and a music file - all worked!

I am now in the process of copying all his precious data back over to his laptop, on which I have installed a new SSD and a fresh copy of W10.

THANK YOU for this thread! It is a life saver! And thanks to essenbe for helping me through the steps. I am a Windows user, and have had only minimal experience with Linux in general, but this thread made it relatively painless for me to accomplish the task. You guys ROCK!

jumanji Anshad Edavana

I would like to thank everyone who contributed to the creation of useful information in this thread.
I succeeded at disk recovery as well:

:info: Case:
1) External drive (USB), long time of serving, ~185 GB capacity
2) Bad data transfer rate on last ~ 10-12GB
3) More data was forced on the device - resulted in a frozen operation, which was interrupted via USB drive unplugging
4) External drive developed inaccessible condition due to a lack of space to fix Usn Journal

:ar: Goal: making a full image of drive, e.g. imaging device to an image file
Anshad Edavana, thank you for this summary:

Anshad Edavana said:

...
4. Avoid using USB enclosure and connect disk drives directly. If the source disk or destination disk is a proprietary external drive which can't be dissembled and directly connected to an internal port, avoid cloning and always take a full disk image.

Click to expand...

:info: Useful resources:
0) SystemRescueCD: click to follow
1) Links to few specific posts in this thread:

• click to follow
• click here to follow

2) DDRescue manual: click to follow
3) Guide to using ddrescue: click to follow
4) Linux commands, useful when using SystemRescueCD: click to follow
5) "Mount" command explanation, examples: click to follow


:info: Useful commands and their explanations:

fdisk -l
Use: lists information on connected devices to the system

mount
Use: lists what is "mounted" or what is accessible (unless locked for a reason)

mkdir /mnt/image
Use: creates a new directory, in this case, it would create "image" folder inside of "mnt" folder)

mount /dev/sdb1 /mnt/image
Use: this command mounts partition "/dev/sdb1" on "/mnt/image"

ddrescue -d /dev/sdc1 /mnt/image/a.img /mnt/image/a.log
Break down:
ddrescue - indicates a command related to ddrescue (should be obvious)
-d - it is one of the possible arguments. There can be multiple arguments as you may have noticed already. More info at: GNU ddrescue Manual
"/dev/sdc1" - (in this case,) partition to save
"/mnt/image/a.img" - path where a full image of "/dev/sdc1" would be written to
"/mnt/image/a.log" - path where a log file would be created at (in this case, near the image file)


:info: SystemRescueCD - can be run in a graphical environment. Once started and in console, type "startx" to enter user-friendly environment.


:info: A set of commands I used in order to recover my data from inaccessible drive:

fdisk -l (Found: sdc1 = partition to save, can be different for you obviously. sda2 = destination partition)
mkdir /mnt/bored
mount /dev/sda2 /mnt/bored
ddrescue -d -r2 /dev/sdc1 /mnt/bored/device.img /mnt/bored/imaging.log

The process took for me about 4 hours to deal with ~185GB drive.
The log file contained a list of up to 15 bad sector records.
Once the image was taken, I restarted the system and proceeded further using the following commands:

fdisk -l (Found: sda2 = partition where image of "sdc1" was saved at. sdb1 = partition where to recover files to.)
mkdir /mnt/finish
mkdir /mnt/finish/dest
mkdir /mnt/finish/reco
mkdir /mnt/finish/save
mount /dev/sda2 /mnt/finish/dest
mount /mnt/finish/dest/device.img /mnt/finish/reco
mount /dev/sdb1 /mnt/finish/save
Once I tried to mount image file - it started to deal with several errors. This took roughly 5-15 seconds, telling me further that the system wasn't properly shut down in Windows.
Then, with the help of graphical explorer/browser, I browsed what's inside the image file (location: /mnt/finish/reco) and would selectively choose what to rescue to: "/mnt/finish/save".

:info: Recommendation to new users:
Before using ddrescue, ensure you know what is the best course of actions for your particular case.
If you are in doubts about arguments to run ddrescue with, best would be to read more and, if possible, test them with other devices.
Also, if you find yourself puzzled whilst choosing PartedMagic or SystemRescueCD - I would flow with SysResCD, because:
1) it's free
2) it doesn't automatically mount connected devices
3) more or less, it has the main functionality that one needs to do the recovery operation

That's all, hope it helps someone.
Thank you guys!

^ A good workout. . Keep up the good work.
( With this in-depth work you had done, you are now in a better position to help others when they seek. I have almost forgotten whatever I did and wrote - can't retain anything in memory . Time to go . In any case this discussion was only a starter and I am glad it is getting embellished by users like you sharing their work done and knowledge gathered..)

jumanji said:

^ A good workout. . Keep up the good work....

Click to expand...

Thank you, jumanji. I thought that the thread was useful to me, so the least I could do to express my gratitude was to enrich it with another successful story as well as covering the key moments I faced with whilst learning the procedure.

jumanji said:

... I have almost forgotten whatever I did and wrote - can't retain anything in memory . Time to go ...

Click to expand...

I am familiar with it ;D

Knowing I might have to redo the research in far future, I thought it would be also a good step to make today.

The majority will look for this information once in 5 or 10 (or more) years. So the probability that we would forget about nuances and steps we had done before - is very high, unless if saved somewhere and often seen. So this information is not the type we would often return to. (exclusion: unless one's job is related to it, or there are enthusiasts who would help others, and etc.)

In fact, there was a time I made a thread, received replies and forgot about it. Three years later, I found that same thread.... You probably know what happened next...

At first, I failed to recognise my own writing until I reached its ending, only then I was shocked. Before I realised who was the author, I already had an impression about him. This was some funny experience as I was able to learn something new.

So should I happen to forget about this thread too... x)

jumanji said:

... In any case this discussion was only a starter and I am glad it is getting embellished by users like you sharing their work done and knowledge gathered...

Click to expand...

Thank you for starting up this thread jumanji.
It was the thread I began my research from and referred to during the process of recovery, and it was without a doubt - useful.
At the same time, I must say that this resource - was also helpful, can't go unnoticed (Thanks SilverLeaf!).

---

Below, a few extra thoughts I've been having, however, none needs to agree or disagree with them:

1) Consider the case: important information is mixed up with other data and that makes it up to 1TB or 1.5TB. The external drive starts to work poorly due to some physical damage and let's say, ended up being inaccessible. Surely one would need 2 TB drive to handle this monster (unless there are other ways to handle this situation that I am unaware of). Depending on the severity of damage, the time needed to process the recovery will vary.

So it kinda dictating the following: keep important data on a smaller available device, so that in case something goes wrong, the recovery procedure wouldn't take ages.

2) important data is safer when one's having a few copies of it on different devices locally (that goes undoubtedly correct).

3) avoid backing up important data online - because this is most likely not in physical reach for you and despite the law, statements, services provided by people in charge there, one never knows what can go wrong on their side (people disobeying the law, hackers, information leak, etc.). Statements do not always ensure the protection, though at the same time, chances that something like this would happen are also low.

You guys are so right.

I'd completely forgotten the steps and need to review once more as there is yet again a need to do so.

Some twists:
Failing drive sometimes shows up in Disk Mgt and sometimes doesn't.
Failing drive sometimes shows up in "fdisk -l" command when booting machine with ddrescue
Failing drive is a DISH network external HDD that wife wants me to try and rescue as it has some shows not available online/netflix etc.
Failing drive seems to Linux

Had a old working drive same size 2TB and wanted to see if I can rescue the failing HDD. But "fdisk -l" command shows the following:

Failing HDD - 2,000,398,933,504 bytes
Good HDD - 2,000,396,746,752 bytes

Failing HDD - 3,907,029,167 sectors
Good HDD - 3,907,024,896 sectors

So, normally it would seem that Good HDD cannot be used to rescue as it has less bytes/sectors than Failing HDD even though the size of both as sold is 2TB.

What would happen if I still try to go ahead? At the most, would I lose some data? Or will the whole process crap out?

Thanks,

Remember that it is a one to one data transfer. The MBR - sector 0 - contains the partition table which defines the start and end sectors of the partition/s. With the endpoint remaining the same in the cloned drive's partition table in sector 0, the actual end sector will be missing in the smaller sector drive. The net effect will be that you won't be able to boot into the partition.

So the effect of doing it with different size is the copied partition table can't match the disk interior and the operation may be fruitless when the disk cannot be read.

If your source disk had multiple volumes then perhaps only the last volume in the destination disk may be unreadable.

Why do you want to lose your sleep? As such the cloning may take days and weeks - depending upon how bad your disk is - and it is always better choosing a larger disk.

You may also need to do quite a bit of research into the latest developments with ddrescue. This thread is quite old and I have almost forgotten all about it .

Hello jumanji,

Thank you for your comments.

Yes need to look more into ddrescue and also get a larger HDD.

Will see how it goes.

Thanks again

Hello,

Looked at ddrescue and amazingly it seems that things will work nearly the same. App has a new interface but the following command still should do the trick.

My only question is - Last time i did not get the recovery.log file anywhere and was wondering if someone can shed a light on it.

The command I'll be using
ddrescue -d -f -r3 /dev/sdb /dev/sdc recovery.log

sdb = Bad HDD
sdc = New HDD

Thanks,

Yep, for most part the basics and commands may remain the same but there may be some changes in the syntax. For example after a certain version logfile was rechristened mapfile.

Normally ddrescue runs from the RAM drive and the logfile also gets saved in it. As long as you do not switch off the PC you can stop and start ddrescue as you may wish. If you shut down the PC the logfile in the memory is lost. You have to start all over again. That is why we recommend " do not switch of your PC till completion"

And yes, by using the Linux command you can save the logfile to a different media. If I remember correct there was atleast one user in this thread who did it and reported it. If you cannot get it, then take help from any of your friends who is proficient in Linux.( My Linux knowledge is next to nil as with most users. that is why the recommendation "do not shut down your PC" to keep it simple without experimenting with Linux )

Note: If you want to research more on it and try to save on a different media then do a trial cloning a small pendrive to another pendrive and make sure that you are able to successfully save the logfile to a third media.

Have come across another twist.

Since this is a 2TB HDD used by Dish Network, if I use a larger size HDD then I need to move data back to a 2TB disk. and these disks would be Linux partitioned disks and hence would need to find Linux commands to move files.

I never shut down the PC the last time I tried ddrescue and hence was confused where the mapfile/logfile went and wanted to see if I can do something that allows me to have this file, though it might not be necessary.

I see some recent posts where users have manually mounted the HDDs and am wondering why did they need to do that. One drives are connected "fdisk -l" would show all the drives that are connected and mounted. Perhaps those people might be able to shed some light on this.

Maybe I'll PM them and ask them to look at this post again

So the issue now is:

Rescue 2TB HDD (with multiple partitions) to 3TB HDD - can be done by ddrescue


Move data from 3TB HDD back to a 2TB HDD - this is where I need some info

nkaufman said:

Have come across another twist.

Since this is a 2TB HDD used by Dish Network, if I use a larger size HDD then I need to move data back to a 2TB disk. and these disks would be Linux partitioned disks and hence would need to find Linux commands to move files.

I never shut down the PC the last time I tried ddrescue and hence was confused where the mapfile/logfile went and wanted to see if I can do something that allows me to have this file, though it might not be necessary.

I see some recent posts where users have manually mounted the HDDs and am wondering why did they need to do that. One drives are connected "fdisk -l" would show all the drives that are connected and mounted. Perhaps those people might be able to shed some light on this.

Maybe I'll PM them and ask them to look at this post again

So the issue now is:

Rescue 2TB HDD (with multiple partitions) to 3TB HDD - can be done by ddrescue


Move data from 3TB HDD back to a 2TB HDD - this is where I need some info

Click to expand...

1)"I see some recent posts where users have manually mounted the HDDs and am wondering why did they need to do that."

Info: Never try to rescue a r/w mounted partition. The resulting copy may be useless. It is best that the device or partition to be rescued is not mounted at all, not even read-only.
Resource: GNU ddrescue Manual

I think it's done to stay on a safe side for the output of an operation to be carried out. In my case, I merely followed that advice for insurance, though, I might have forgotten of something by now (after all, it's been a while since the last time I made a post here).



2) "I never shut down the PC the last time I tried ddrescue and hence was confused where the mapfile/logfile went and wanted to see if I can do something that allows me to have this file, though it might not be necessary."

jumanji said:

Normally ddrescue runs from the RAM drive and the logfile also gets saved in it. As long as you do not switch off the PC you can stop and start ddrescue as you may wish. If you shut down the PC the logfile in the memory is lost. You have to start all over again. That is why we recommend " do not switch of your PC till completion"

Click to expand...

It offers options on how one wants to begin a session with ddrescue, e.g.:

1) running it from memory
2) running it from memory but in graphics
3) running it from source device
4) .... etc

Though, if you meant by "normally" the fact that the most would go by this option -> forget my words earlier ;D

So, nkaufman, it doesn't matter what mode you used, be it RAM or real source, you would most likely find the log file somewhere at the root directory given you are in that same session of ddrescue. The RAM mode won't keep a hold of your log file upon system's shutdown/restart/etc. However, if you run ddrescue from its source storage, then it should write it to there, unless it cannot be done so. Consider the case if you run ddrescue from a CD which you burned, but your CD-ROM cannot write or burn more information to it. Given this situation, if I am correct, then this scenario won't hold your log file as well.

If you run ddrescue from a pendrive/memorystick - it should be able to write data to there as it goes, unless it happens to have a feature to switch in-between modes: "read only / read and write", which would be in "read only" mode, e.g. cannot write any data to it -> log file won't be saved.

If you like to be sure regarding log file, do add a path to it and make sure that the place you are about to write it to, is "writable". Here is an example, in fact, it's how I went about the log file myself back then:

" A set of commands I used in order to recover my data from inaccessible drive:

fdisk -l (Found: sdc1 = partition to save, can be different for you obviously. sda2 = destination partition)
mkdir /mnt/bored
mount /dev/sda2 /mnt/bored
ddrescue -d -r2 /dev/sdc1 /mnt/bored/device.img /mnt/bored/imaging.log "

What's in bold style - it's essentially log file's name and these slashes in its name are recognised as its location pointers, e.g. mnt = must be "a folder" because it is followed by a slash, bored = must be "a folder" too because of a following slash, imaging = is its name because after it follows a 'dot' which defines file's extension, e.g. "log". If I don't mistake, it doesn't matter what extension you assign to it, as long as you attempt to read it in notepad or alike text editor, but never mind on this nuance.

There is nothing wrong by giving it a specific path, in fact, it only helps you find it with ease. if you do add path, make sure you memorised it or had taken a note of.




3) "Move data from 3TB HDD back to a 2TB HDD - this is where I need some info"

I would be interested to read a solution solving a case like:

2TB data holding up to 500 GB, needs to be recovered on a device with capacity equal to 512 GB / 1 TB.

I think, somewhere earlier there was a discussion about it (it was cloning method I think), I am to review it later though.
Anyways, I wonder if it is possible to retrieve 500GB of data from that 2TB device via imaging method, to a device with capacity of 1TB...