Re: [dm-crypt] Device /dev/md2 is not a valid LUKS device

[Arno Wagner <arno@wagner.name>]

On Mon, Feb 18, 2013 at 07:28:41PM +0100, Stone wrote:
> hi guy's.
> 
> i new in your mailing list and i have a problem with my setup.
> 
> today my raid5 degraded totaly and i can fix it with a command to re-created
> /mdadm --create /dev/md2 --assume-clean --verbose --level=5
> --raid-devices=4 /dev/sdc1 /dev/sdd1 missing /dev/sdf1/
> After this i add my /dev/sde1 also to my /dev/md2 device.

Arggghhh, never, ever create a new RAID on top of the
components when trying to recover one! Unless you have 
exactly the same parameters and same component order
(and possibly same mdadm version), this does not work,
but will destroy data.

You have now completely wiped the old RAID metadata and 
potentially wiped the LUKS header and/or keyslot-area. 
The right way to do this is to
 
1) Make a complete backups (binary) of the RAID components
2) force assembly (not creation) with the components
   present at the end and the component that fell out
   of the RAID last. That ususlly gives you a complete
   or almost complete recovery.

Also, why did the RAID degrade?

> My problem is now the i cannot open my crypt device
> /cryptsetup luksOpen /dev/md2 md2_nas//
> //Device /dev/md2 is not a valid LUKS device./

Several possible root-causes come to mind:
- Wrong component order
- Wrong spuperblock placement 

> Befor one year i has the device created with this command:
> /luksformat -t ext4 /dev/md0/

Did you re-name from md0 to md2 at some time?
 
> A dont have a backup of the header.
> 
> Is the filesystem broken?
> /fsck /dev/md2//
> //fsck from util-linux 2.20.1//
> //e2fsck 1.42 (29-Nov-2011)//
> //fsck.ext2: Superblock invalid, trying backup blocks...//
> //fsck.ext2: Bad magic number in super-block while trying to open /dev/md2/
> 
> Is there a chance to get my data from the device?

Well, maybe. If the medatata-placement did not destroy
the header and key-slot area, then you can in theory reconstruct
the data that the adding of sde1 overwrote. Basically,
some areas of sde1 will now hold plain data while the raid 
controller thinks it is parity and some areas will be the 
other way round. Some areas may even be fine. 

If this were non-encrypted, you could use some commercial
raid recovery software, but with encrypted data it has 
nothing to latch onto to guess the right geometry. Basically,
you would have to manually reconstruct first the LUKS
header and key-slot and then guess the original RAID 
geometry. You cannot even decrypt the components individually,
as you need to correct sector numbers for decryption to work.

I would say the effort is very likely not worth it.  

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
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