[dm-crypt] Corrupt LUKS-Header

[Nicolai Voget <nicolai@nicolaivoget.de>]

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]

Hi there,

on my home server I've got a RAID 5 consisting of 3 hard drives that
contains a dm-crypt partition with ext4.
Today, one of the 3 drives passed out and afterwards I got some
ext4-errors in dmesg.

Unfortunately I'm not home right now, nor for the next 4 days, so I
can't replace the harddrive, although I even think it's not necessary,
because it was just the USB-controller that passed out. Nevertheless, I
wanted to run some e2fsck on the partition to check whether there are
some errors or what dmesg was talking about.
Stupid me, I forgot that the partition was decrypted, so I ran the
e2fsck directly on the md0-RAID. Of course I got some errors, but didn't
really think about it, so e2fsck did some error correction, but
eventually it seemed weird, so I interrupted it. (I've attached the
output, e2fsck showed me, maybe it helps)

Of course, the LUKS-device won't mount any more for the LUKS header
seems to be overriden. Fortunately, the drive that passed out of the
RAID earlier (sda) has been the first device of the raid, thus holding
the first 64k (that is, until 0x10000) of LUKS-data (starting with "LUKS
… aes …" and so on). Unfortunately, the modification by e2fsck went on
to the second 64k of data, too. But by comparing the (original) data on
sda with that on md0, I can say that anything from 192k upwards
(0x30000) seems to be fine again.

Is there any chance of getting the missing data back? As far as I know,
there are some methods to get the data, that has been stored in a block,
although it has already been overridden. By the fact that I have one of
the drives unaltered, it should be possible, to judge which combinations
of data for the other two drives can be possible, because the must xor
to the data of the first drive, isn’t it?

I would be extremely thankful if anyone could help me out on this.

Regards,
Nicolai

[-- Attachment #2: e2fsck-output --]
[-- Type: text/plain, Size: 2004 bytes --]

e2fsck /dev/md0
e2fsck 1.41.12 (17-May-2010)
e2fsck: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Clear<y>? yes

*** ext3 journal has been deleted - filesystem is now ext2 only ***

/dev/md0 was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate<y>? yes

e2fsck: Illegal triply indirect block found while reading bad blocks inode
This doesn't bode well, but we'll try to go on...
Pass 1: Checking inodes, blocks, and sizes
Bad block inode has illegal block(s).  Clear<y>? yes

Illegal block #0 (1944878064) in bad block inode.  CLEARED.
Illegal block #1 (1576054459) in bad block inode.  CLEARED.
Illegal block #2 (2603946801) in bad block inode.  CLEARED.
Illegal block #3 (3721147353) in bad block inode.  CLEARED.
Illegal block #4 (843436927) in bad block inode.  CLEARED.
Illegal block #5 (2785300981) in bad block inode.  CLEARED.
Illegal block #6 (2792029489) in bad block inode.  CLEARED.
Illegal block #7 (2223358637) in bad block inode.  CLEARED.
Illegal block #8 (1903446826) in bad block inode.  CLEARED.
Illegal block #9 (2220861675) in bad block inode.  CLEARED.
Illegal block #10 (3344075755) in bad block inode.  CLEARED.
Illegal block #11 (3784337891) in bad block inode.  CLEARED.
Illegal indirect block (4030283823) in bad block inode.  CLEARED.
Illegal double indirect block (3050192542) in bad block inode.  CLEARED.
Illegal triple indirect block (3271645712) in bad block inode.  CLEARED.
Root inode is not a directory.  Clear<y>? yes

Inode 3 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes

Reserved inode 4 (<The ACL data inode>) has invalid mode.  Clear<y>? yes

Inode 4 has compression flag set on filesystem without compression support.  Clear<y>? yes

Inode 4, i_size is 11409684805389471492, should be 0.  Fix<y>? yes

Inode 4, i_blocks is 25110402, should be 0.  Fix<y>? 

Recreate journal<y>? cancelled!

/dev/md0: e2fsck canceled.

/dev/md0: ***** FILE SYSTEM WAS MODIFIED *****