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

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.

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

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"

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...