I have a known bad hard drive with bad sectors and I am trying to recover data from it. I tried ddrescue, but the image is trash. I compared the bad drive to the ddrescue drive and they are identical. Doing a e2fsck -b superblock change, just fails on the rescue image. On the bad drive, it is attempting to fix it, but I continually am getting the above error. I keep hitting yes to ignore the error and force a rewrite, hoping that it will fix, but dont want to waste my evening if it is futile. It seems I have to partially fix this drive, before I can do a ddrescue on it. ??

No. That is -NO! DON'T try that!
If you want to rescue stuff from a faulty drive you do *not* do anything on the drive itself! Each failed try will make rescuing more difficult.
You are on the right track with ddrescue, it simply makes a raw copy of the drive - complete with all errors.
When you have this copy, copy it to new image file and work on that.
When all is screwed up, just copy original image again - much faster than doing a new ddrescue.
I have rescued data from a few drives myself with this method, unfortunately I haven't used it enough to be able to guide you in what steps to take.
I just felt a need to tell you to never try anything directly on a faulty drive! *Always* take a copy to work on.
If everyting fails you might have to let professionals do the rescuing (only company I know of that can do this is Swedish IBAS, surely you have a few in your country). Every little attempt you've made on the drive itself will make their bill higher, and if you're very unlucky you might make rescuing impossible.

I understand what you are saying. I did make a dd image of the drive, and I then restored that on a good drive. ANY attempts to do anything to it, failed. Yet, when I went to the failing drive, it let me fix it. Very odd. In any event, in this manner I was able to recover 98% of the files. I got very little from the image. I must have done something wrong. In any event, I wished I had more time to play with this. The problem is now a days, a 2-4TB drive takes FOREVER to do anything with.

Ok, glad you got most of it back!

Let me just say that you don't need to put the image on a new drive, instead mount it directly:
mount -o loop /path/my.iso /mnt/whatever
You can then do anthing on it just as if it was a real drive.

Really! I did NOT know that. I thought a dd image was not mountable. That would be cool. I will have to go try that. As luck would have it, I had done a complete backup just 3 days prior. That drive with my backups I thought was the one that for some reason lost it's mind at the same time I had hard drive failure. Unknown partition and test disk just can't seem to figure it out. Since I have the file backed up, I didn't want to waste any time on it, but wanted to "educate" myself on restore. I finally gave up that too. I wonder if it is because the head count is wrong. Something just is not making sense. I don't know if it is these new drives, or what. It thinks there is 255 heads, which of course it does not. Since ide translates, it is hard to know without doing a LOT more digging, and I am growing weary of banging my head against the wall when I don't need to. If I have room, I may dd it to play with later.

Or maybe, if you just want to educate yourself, I humbly suggest you play around with a smaller disk.
As you said earlier - "The problem is now a days, a 2-4TB drive takes FOREVER to do anything with."

And you had a backup, way to go!
That is far too unusual, thumbs up to you!

LOL... 80gb drives are all gone my friend. The smallest thing I have is a 750TB drive these days. I wished I DID have a smaller drive that was going. The one thing I DO have is a 28gb sda1 partition that I have dd'd, so I can play with that later. It just doesn't have the puzzling issue with a missing partition, like that 2tb drive has. Oh well... It has still been an educational experience. I am learning the kiss principle applies!!! I used to do RAID arrays for the boot disk, but in the end, it just makes recover 4 times harder to impossible. I had my /tmp, and /home directory on another drive. I think that too complicates things. I put the /tmp on a big drive, because if /tmp fills up on a small partition, it brings the drive down. So I need to come up with a plan to warn me when it starts getting full. I am now migrated to a bigger drive so that I can have /home and /tmp on the same drive.

Say, I have a question for you. I have used rsnapshot for a couple of years now, but I was not backing up bin, dev, lib, lib64, opt, proc, and run. Clearly I cut it too thin, because the restore didn't work out too well. I'm thinking I need lib and lib64 as well, what else? Thanks for the quick response. Have a great day.

Yep, you definitely need lib and lib64. Also bin and opt - IIRC, only skip dev, proc & run, backup everything else.
(Well, otoh, just reinstalling goes pretty fast if you keep the system separated from user-files which I believe you do.)
You can actually try it:
Boot from a live-cd (or from another system if you have more than one installed).
Then copy first system except /dev /proc /run to a new partition - you'll have to create these directories on new system but leave them empty.
Edit grub & /etc/fstab.
Boot new system, check that everything works.

And that about the "kiss principle", how about this:
2 years ago I built a storage server for my music & movies.
I was very broke, so I took 5 smaller disks and "bunched them together" using LVM (same principle as raid0, several physical disks creates one logical).
After a few months one disk crashed...
It took me DAYS to recover from that!
---
Edit:
And if you want, I can send you a bunch of ide-disks, 20-40GB in size!
(Just don't ask why I still have them... )

Thanks, I'll tweak my script to include those from now on. If there is a next time, then it should be MUCH less painful. At least I didn't lose any critical data. I just lost way more time than I should have. This is good info to have. I appreciate it.

==========
And that about the "kiss principle", how about this:
2 years ago I built a storage server for my music & movies.
I was very broke, so I took 5 smaller disks and "bunched them together" using LVM (same principle as raid0, several physical disks creates one logical).
After a few months one disk crashed...
It took me DAYS to recover from that!
==========
OH yes... been there done that!! NOT fun. I have a couple of old used drobos... they are flakey, but half the time when a drive fails, I can recover. :/


===========
---
Edit:
And if you want, I can send you a bunch of ide-disks, 20-40GB in size!
(Just don't ask why I still have them... )
==========

Hahah.. I still have an old st225 drive. Those old 20mb drives. I have one big full height 500mb drive that weighs about 5 pounds. I have kept an old read write opptical I bought. Cost like $3,500 in the day and was a disaster. Kind of the predecessor to the cdrom I think. The first two I keep for fun, the last one just takes up space but can't bare to throw it away. hahah

PS. To anyone contemplating a multi drive system.... document!!! I figured I'd never forget. After all I was the one that set it all up, but over time, things change and memories fade. I started out with a 1TB drive... ran out of room and added a 2tb drive. Moved /home there. Then /tmp kept filling up, so I moved that to another drive. Well.. all those drives, not labeled, and not documentation, after I figure out what drive has failed, and cables get moved.. well you get the idea. Just label the cables, document what you have done, and tuck it into the case. At least it won't get lost, and it may help rebuilding later. Ask me how I know.

Mounting loopback works only if you copy a single partition.

IF you copy an entire physical drive, then you also get the partition table of that drive... and cannot mount it because the partition superblock is not at the right place of the image copy.

To mount disk images with a partition table requires you to decode the partition table to compute the necessary offset to the beginning of the partition...

No it doesn't: just use 'kpartx'.

Thanks, had not need that yet. Good to know.

I know this has started drifting, and I'm sorry for that. As you know I have a dd image of a partition on a drive that was going bad.

I attempt to mount as explained above.

mount -o loop image.dd /mnt/tmp and I get
I get mount: unknown filesystem type '(null)'

So since it is damaged, I'm guessing that I have to somehow fix it with a tool. ??

If you have 'disktype' run
then read (and attach?) "/tmp/disktype.txt".
If you have 'testdisk' run
select Proceed > Intel > Analyse > Quick Search > N > (Enter) and press "q" until you have exited the application, then read (and rename to ".txt" extension and attach?) "/tmp/testdisk.log".

--- image.dd
Regular file, size 28.61 GiB (30720131072 bytes)
First 1 MiB (1048576 bytes) are blank

I then brought up testdisk as you suggested and it saw the partition. I selected W to write it to the image. It says you have to reboot, but since it is an image, I'm thinking a reload attempt is not in order.

mount -o loop image.dd /mnt/A
mount: unknown filesystem type '(null)'

Surely a reboot isn't needed. I'm in the middle of some data moving to finish cleaning up my "mess".