fwors wrote:
budget: I don't spending a little money if it significantly increases the chances of recovery. However, in general I prefer open source solutions.
You could consider using that budget to ask a suitably-equipped DR company to perform a cloning-only recovery attempt, where you also provide the target disk for them to use.
If you are happy using open source solutions, and recognise that they are more limited than the best dedicated imaging tools (e.g. no power control etc.), then ddrescue is one tool which I have used.
fwors wrote:
time: There's no hurry and I don't mind spending some time with this.
experience: I have recovered deleted files from USB devices, but haven't dealt with any serious data losses involving hardware or "low level errors" like corrupt file tables.
[...]
I haven't use Linux in a while
Since you have the time to do this, and given the lack of recent experience with Linux, I suggest that you get familiar with ddrescue by practicing cloning another disk onto your planned target disk. For example, if you make a mistake and swap the source & target of the ddrescue command, then you will irreversibly lose data, so you want to be sure you know enough
not to do that. You must use the ddrescue logfile. I don't give step-by-step instructions for ddescue, as so much depends on what happens when it runs, but I've given a couple of comments below.
fwors wrote:
if ddrescue is the best (free) software available I am going to use it.
I'm not going to tell you that it is "the best", as that is a subjective conclusion, depending on what parameters you're measuring, what weighting you give to each parameter etc. For ease of use, it probably scores lower than some free Windows-based cloning software, but with that complexity, comes flexibility and control.
I would probably start with a larger-than-default read block size, and no splitting configured, for the first pass - in an attempt to get a partial clone quickly (even though it is incomplete with no attempt to re-read any unreadable blocks), using a logfile as I mentioned above. Then re-run ddrescue with an appropriate direct or raw mode configured (depending on your Linux kernel's capabilities), as well as a few retries and splitting allowed, in an attempt to fill-in the unreadable "gaps" of that initial quick (but incomplete) clone. However, depending on what happens (e.g. one part of the disk seems very slow), then the plan would need to be changed to move on and get as much as possible from the parts where retries are successful, before the drive fails catastrophically (as
BlackST mentioned could happen).
fwors wrote:
Are there any distributions with pre-installed recovery tools available?
Yes, there are some. For various reasons I don't use one, but an example is:
http://ubuntu-rescue-remix.org/fwors wrote:
Besides, is it possible to limit the image to the second partition? I don't need any files from partition C and reading 150 GB unnecessarily from a damaged disk doesn't too promising.
Yes - I suggest you review the Linux device node naming scheme. For example, on a disk /dev/sda using MBR partitioning, its first partition (often, but not always windows drive C:) is /dev/sda1 while the second partition (often, but not always Windows drive D:) is /dev/sda2 etc. You can find the correct partition number for the partition(s) you want to read using fdisk -l to see the partition sizes, assuming that the MBR is still readable.