On Sat, Aug 25, 2012 at 08:14:34AM +0200, Andr?s Korn wrote: > Hi, > > I had an mdraid5 array made from four partitions of four disks, and > had LUKS on top of it. > > One of the drives developed a few bad sectors (but didn't fail > completely), so I replaced it. While the array was resyncing, one of > the other drives threw a few errors, so mdadm marked it as failed and > stopped the array. > > At this point, I made a mistake. I re-created the degraded array with: > > mdadm --create /dev/md2 --level=5 --raid-devices=4 --assume-clean > missing /dev/sda4 /dev/sdc4 /dev/sdb4 > > However, I forgot to specify --metadata=0.90 (which the original array Not good. Never, ever, ever recreate RAID arrays, filesystems, etc. without a full binary backup of the originals, unless you are prepared to lose all data that was on the devices. > used). I immediately rectified this, but by then mdadm had written a > raid superblock somewhere where originally there was none, and now > trying to luksOpen the volume with a known good passphrase results in > "No key available with this passphrase". The default is metadata 1.2 for current mdadm. That put the superblock at 4k from the start and right in the middle of the first key-slot. > I still have the drive I removed, intact. It is unlikely but possible that what you lost is on there. To determine this you would need to find out where exactly the mdadm superbloick landed, extract the rest of the key-slot and see whether you dinf that on the removed disk. If so, you may have the data missing from the key-slot on the removed disk. > I have some backups but they're older than I'd like; is there anything > sensible I might to that could help me recover the LUKS volume? Not really. The only faint hope is to have the missing data on the removed disk. Nothing else that I can see. Chances are roughly 25% that the missing part is on the removed disk. So unless you want to do some serious digging through raw disk data on sector-level (and possibly writing some tools for that yourself), no, nothing sensible. > My first idea is to re-create the array with the removed drive > included (making sure to specify the metadata version). T Don't do that! It will likely only destroy more data. > his entails > uploading ~1TB over a 10MB/s link, so I thought I'd ask first whether > this had any chance of succeeding at all, or whether there was > anything else to try. See above. The one, most important rule for data-recovery is though: ==> Never ever ever write anything to the originals! <== You can try to puzzle the header back together on different media, you do not need a data area. You can alos use a detached header (newer cryptsetup) and work in a file. As soon as you get an unlock, you can then try to repair the old header with the recovered one, but not before. Of copurse all of this will require digging deep into the RAID metadata on-disk formats, the LUKS header format (FAQ Item 6.12 has the short version). You may also have to experiment to recreated the RAID disk order, stripe size, etc. by finding and recovering the 0.90 metadata block. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
