On Mon, Nov 14, 2011 at 08:03:26PM +0100, Nicolai Voget wrote: > 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 No. Not for modern HDDs. At least nobody admits to being able to do this and there are some rather strong indicators it is fundamentally impossible. > 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. If your LUKS container is still mapped, then you can get the master key. This is your _only_ chance, unless you have a header backup. See FAQ section "6. Backup and Data Recovery" item "How do I recover the master key from a mapped LUKS container?" The FAQ is here: http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions Arno > 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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
