Just a couple comments from a couple similar experiences I had...
The first is to figure out the mode of failure of the drive.
Is it from a laptop that was dropped during use?  Is it a drive that
is having sectors go bad?  Did someone do something silly and start
writing zeros to the wrong device?  (not that I've ever done that...)
Different modes of failure may require different tactics, and can also
have very different results.

On Tue, Apr 13, 2010 at 9:49 AM, Ryan Coleman <ryanjcole at me.com> wrote:
> I was given leads to using ddrescue and dd but frankly that is outside of my
> realm of knowledge and 9 of the 10  NTFS partitions that refused to mount in
> Windows have mounted so far in FreeBSD (I'm running 8.0).

ddrescue might be VERY useful in this situation.  If you're not
familiar, it is basically dd, but it is forced to keep reading (and
writing) on when it encounters bad blocks.  Some of the files will end
up corrupt in the disk image you create, but if you are fortunate, the
lion's share will be there.
You just want to start with the failed drive readable to you, and with
a location you can write the output file to with more space available
than the size of the partition you are trying to recover.
Both dd and ddrescue use similar syntax.  As I recall there is a
slight difference, but starting with the basics, you should be able to
figure out the rest...
I think the command I used was: dd if=(path of the device name for the
partition to be recovered) of=(path of the file name to create from
the partition)
Certain other flags may be necessary, and ddrescue may be the
preferable command.  The less times you have to try the better.  If
the drive's condition is getting worse with use, you want to use it
less if possible!
I would expect it to take a LONG time.
Once the process is complete, you can try to mount the output file as
a loopback filesystem.  (under Linux, I believe the flag is "-o loop")
 If you're able to mount it, you should be able to copy any important
files off of it and then weed out what is intact and what is corrupt
without dealing with i/o errors in the middle of trying to copy a
batch of files.

> The drive is presently connected via USB on a SATA sled.
> I know that there's something to be had on there somewhere:

Personally, I would try to use the most direct connection possible.
SATA direct to the motherboard first.  Maybe it's just my dislike for
middlemen...
- Justin