I found instructions for dd_rescue for outputting an image file, but in the ddrescue manual there were none, so I went on with what I had at hand.
This meaning, there was nothing out of the above discussed, that I wanted to do: Restore files, check, if possible, which ones have not been salvaged and save them to my regular data drive.
The ddrescue manual's first example outputs an image file (hdimage). That is not the same as restoring files. It simply means copying the drive's data to a very large file which can then be manipulated (compressed to save space, fingerprinted and so on) by any program.
The manual also explains a trick to mark bad files from a recovered partition irrespective of the file system involved. But most of the operations you talk about are FS-dependant and therefore outside the scope of ddrescue.
If the drive isn't too badly broken and ddrescue is able to do good job, there'll be nothing special to do after ddrescue has finished recovering the data from the bad drive (just access the imaged drive like a regular drive, assuming the partition table is valid).
One (well, another) foolish thing I could have done is that I've used the drive that had produced a specific number of bad sectors (data copied from it to a replacement drive already) but is now stabilised - have stress tested it a bit - to save the data from the failing drive
If it passed your stress-testing, you'll probably be alright.
It's not the safest thing but I don't throw away drives as soon as they get a few bad sectors. Most of them can still serve for years as backup drives and so forth (if you go by the "at least three copies" rule, it's OK if some of them are on somewhat dubious drives).
Well, I don't have much experience, but aren't 3 just too few? I don't know that the time-cost effect would be setting retries to 6-7, but I would -unknowingly- take that as minimal.
About the errors, you mean bad sectors? There must be over a thousand there.
Right now, with the parameters ddrescue is running, it has come across two of them.
Well, I'm pessimistic. If it doesn't work after three attempts...
But you have only two errors with about 19MB to retry, right? It shouldn't take ages to retry these aeras many times so go ahead with your optimistic (or desperate?) settings.
What do you mean by the "Microsoft way", exactly? The check disk utility?
Whatever Microsoft recommends (they probably have some KB article about this). That would certainly include chkdsk but maybe they recommend something else in addition in case the drive has gone bad. I've never needed anything else except when the data was overwritten or the drive was totally shot (that's beyond the help of any software). So if you could run chkdsk without affecting your image or on a copy of the image, I'd simply try chkdsk. But if you have only one shot at this, maybe you should check out Microsoft's documentation first.
From what I read around people might also use the "test disk" utility or other software that focus on recovering data from damaged partitions (instead of actually repairing them)
Yeah, that's what I called "recovering [your data] from the raw partition". I think ddrescue's manual mentions such a tool: photorec
I've never used Testdisk but it sounds like it can do more than just that and tries to package several capabilities in a user-friendly way. It may have done the ddrescue operation (or equivalent) for you.
So, since I won't actually be keeping the drive that I use for restoration, maybe I could afford not to dwell too much on file system repair? Of course I don't know what is worse, trying to fix the file structure or restoring files from damaged file structure.
It doesn't matter is you're going to keep the drive or not. What matters is:
-do you know what files you want to recover? can these files be identified? if not, you'll need to fix the file system
-how many files do you want to recover? if there are many, it might be simpler to try to fix the file system
-do you care about recovering files names and location (as opposed to the contents alone)? if yes, you'd better try to fix the filesystem
Files can be identified most easily in the raw partition with plain text strings they might contain or because they have some other kind of marker such as magic numbers (only useful if you don't have too many files of the same type). Check out photorec and get some idea of what it can and can't do.