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: 0x2fa13928

Device 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/

And then back in the Windows world, you can use truecrypt to mount 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.


Write a comment