So you have a hard drive encrypted using Truecrypt. A very good solution to keeping data secure, but it does make your data more fragile. When* the drive goes TU, you can’t just run a recovery program on it, because encryption.
And of course so it came to pass. My hard drive developed read errors.
First thing, make a backup copy. For this you need a Linux box and ddrescue. And a large drive to recover to.
# ddrescue /dev/hdb /mnt/large-disk/diskimage /mnt/large-disk/logfile.log
(This takes a while, but when it’s done you can unplug your faulty disk, save it as much trauma as possible)
You now have an image of the whole disk. You want an image of the partition.
# fdisk -lu diskimage
Disk diskimage: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x2fa13928Device Boot Start End Blocks Id System
diskimage 63 976768064 488384001 7 HPFS/NTFS
Your partition starts at “Start” x “Units”, which would be 63 x 512 = 32256 in this case.
# losetup -o 32256 /dev/loop0 diskimage
You can now attempt to recover /dev/loop0. I found this easier in Windows, so
# dd if=/dev/loop0 of=/mnt/nfs-volume/diskimage.tc
And then back in the Windows world, you can use truecrypt to mount diskimage.tc and if you’re very lucky your files will be there. If you’re unlucky, truecrypt won’t recognise the image as a truecrypt volume, and you’re in more shit than I can help you with today.
In my case, truecrypt mounted the volume but Windows did not recognise it as a drive (i.e. a corrupted file system). There are tools for this. Unfortunately most of them work on physical disks, not virtual ones. Thank Finagle for google, who told me about GetDataBack. Specifically, GetDataBack 4.25. Pointed it at the virtual disk (G:) and it recovered all my files with absolutely no worries.
* Not if.