How to Rescue Data From a LUKS Encrypted Filesystem

With 10,000 laptops stolen from airports alone each year, data encryption is an absolute must. What happens, then, if your fully encrypted  system crashes and won’t boot? Here, we’re going to cover how you would go about recovering that data if it is encrypted with LUKS.

LUKS is an encryption standard most commonly used on Linux but can be used on other systems. It is the basis of Ubuntu/Debian’s (as well as others’) filesystem encryption, which can be installed using the alternate installation disc.

What you need:

The LUKS passphrase (Without that, you are out of  [ahem] luck. Otherwise, what would be the point of encryption.)   :)

Something to copy your data to like a USB drive or another machine on your network. I recommend this even if you are planning on fixing/rescuing your OS. This way your data is backed-up and safe no matter what happens afterwards.

A “live CD” like the Ubuntu desktop installation disc or a Debian installation disc.

The process:

- Boot the crashed machine with a “live CD” such as Ubuntu 4.09 or the Debian installation disc in recovery mode. When I did this on my own drive, I used an Ubuntu live CD. If you are using the Debian installation media, boot into rescue mode.

Become root to simplify things more:

sudo su -     (if using the Ubuntu CD)

su -                (if using pretty much anything else)

Install the needed LVM and encryption tools:

apt-get update
apt-get install cryptsetup

Check to see what your device names are:

fdisk -l

You’ll see something like:

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x41ab2316

Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1       18701   150215751   83  Linux
/dev/sda2           18702       19457     6072570    5  Extended
/dev/sda5           18702       19457     6072538+  82  Linux swap / Solaris

Take a look at your LUKS header information here to ensure you’re going after the right one:

cryptsetup -v luksDump /dev/sda1

The first several lines of output should look something like this:

LUKS header information for /dev/sdb1

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 2056
MK bits:        256

If you ran luksDump on a partition not encrypted with LUKS, you’ll get a message like, “Command failed: /dev/sda1 is not a LUKS partition”

If that’s the right device, then go ahead and unlock it:

cryptsetup -v luksOpen /dev/sda1 sda1_crypt

The system should prompt you for a password and after entering it, you should see something like:

key slot 0 unlocked.
Command successful.

See which volumes are available:


Enable your logical volume. It is probably the same as the machine’s host name:

vgchange -a y volumename

Mount your filesystem:

mount -t ext4 /dev/volumename/root /mnt

Hopefully you can read your file system at this stage. If so, grab your files and back them up.

If the filesystem is corrupt and you can’t mount it, you can try the following. Your data may be lost if the filesystem is wrecked but it’s worth trying a few things to retrieve it.

Be sure the filesystem is not mounted when you do this. Also be sure to use the proper type of fsck (fsck or fsck.ext4) for your filesystem type. BIT ENGINE takes absolutely no responsibility for what happens when you perform these tasks — even if you follow them exactly as specified.

To identify where back-up superblocks are

dumpe2fs /dev/devicename | grep superblock

If your filesystem type is ext2 or ext3:

fsck -b 32768 /dev/devicename  (substitute 32768 for a back-up superblock in the list from the output of the previous line)

If your filesystem type is ext4:

fsck.ext4 -b 32768 -y /dev/devicename

Hopefully, that fixes any errors. Try mounting again:

mount -t ext4 /dev/volumename/root /mnt

If your journal is messed, you can try:

tune2fs -j

Then try mounting again:

mount -t ext4 /dev/volumename/root /mnt

In my situation, my filesystem and journal were corrupt. After running fsck.ext4 (I run ext4, obviously) and tune2fs -j, I was able to mount it and search /mnt/lost+found for files (find /mnt/lost+found/ -name *.odf should get you there, substituting odf for whichever file type you need). Fortunately for me, all my important data was backed up and I was going through this as a test run in case I needed to do it in the future.

The biggest lesson here is one that can not be overstated: always back-up your critical data! Keep back-ups current and to a secure medium.

This how-to was created with a lot of help from this document and a little help from this one.

Leave a Reply