Due to a combination of hardware failure, ignorance, and stupidity I have managed to really make a mess of a 7 drive mdadm (raid5) -> lvm -> luks -> ext3 setup. So here is the basic setup: 1. sudo badblocks -c 16384 -s -w -t random -v /dev/sd (on all 7 drives) 2. sudo mdadm --create --verbose /dev/md0 --level=5 --chunk=256 --force --raid-devices=7 /dev/sd[a,b,c,d,e,f,g] 3. pvcreate /dev/md0 4. vgcreate lg /dev/md0 -s 256M 5. lvcreate -l22356 -nlv lg 6. cryptsetup --verify-passphrase --verbose --hash=sha256 --cipher=aes-cbc-essiv:sha256 --key-size=128 luksFormat /dev/lg/lv 7. cryptsetup luksOpen /dev/lg/lv encrypted 8. mkfs.ext3 -j -m 3 -O dir_index,filetype,sparse_super,large_file /dev/mapper/encrypted So long story short, the hardrives were swapped around and one point which cause blkid.tab to go crazy and remap the drives to different letters. All but one of the mdadm superblocks were erased, but I believe the array was clean before this happened. By using basically the same command first used to create the array mdadm detected that it was already a raid array and recreated it - unfortunately it thought that the last drive (sdh at this time) was dirty, and thus began rebuilding it. Unfortunately commands 3-7 were also reissued, which initially made me believe that the luks header was destroyed (according to this thread: http://osdir.com/ml/linux.kernel.device-mapper.dm-crypt/2005-12/msg00045.html). After some time with dd and a hex editor I have found three luks headers on the drives - two of which are the new header; however it is my hope that the other one is the original luks header. I now believe that mdadm did not correctly recreate the raid array, primarily because that luks header was not wiped out and the array was created with the drives in a different order. I do not believe that the drive that was being rebuilt ever completed (this may be useful for rebuilding the raid array in the correct order?). At this point since there are so many ways that I could be SOL, I think the first step is just for me to verify that the luks header I recovered is the correct one. Anyone have any advice on how to do this? I already dd'd the first 4mb of each drive in to files, but I am not really sure how to proceed. Will I have to trick cryptsetup in to thinking its a device? Is there a way to simply decrypt all the data on these little chunks? I will probably have a problem with data alignment due to the cryptsetup being applied after mdadm and lvm, both accross the chunks and on the individual chunks... is there anyway to fix that? Are there any tools similar to R-Studio for linux? If this is in fact the correct key then I think that I may still be able to recover most of my data, as I do not believe much other than the various headers have been corrupted... Thanks for your help, -Clay
