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
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 *****
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
