On 06/02/2018 06:51 PM, page p wrote: If it is supposed to be a LUKS device, then you should not be able to see the XFS filesystem. Can you show us the exact commands you are trying and the result? You can use "file -s" to make it look inside device nodes. So, for example, you can do "file -s /dev/md0" to see what the RAID array is.

Le 03/06/2018 à 08:39, page p a écrit : Is there any inconvenience to have an array with number 127? -- François Patte UFR de mathématiques et informatique Laboratoire CNRS MAP5, UMR 8145 Université Paris Descartes 45, rue des Saints Pères F-75270 Paris Cedex 06 Tél. +33 (0)6 7892 5822 http://www.math-info.univ-paris5.fr/~patte

On 06/02/2018 11:39 PM, page p wrote: What does "file -s /dev/sdb1" give you? If it tells you it's XFS, then you might be able to mount it directly and get the files off before rebuilding the array again.

On 06/03/2018 08:46 PM, page p wrote: Try "mount -t xfs -o ro /dev/sdb1 /mnt/localhost-sdb1". Make sure you stop the array before accessing the individual drive. And include the "-o ro" as above to avoid modifying the filesystem as well. Yes, I'm a little confused about what has happened. If you really setup LUKS, then you shouldn't be able to see the XFS filesystem. I guess you'll find out if you manage to mount it.

On 06/03/2018 10:35 PM, page p wrote: Did you stop the RAID array? "mdadm -S /dev/md127" What is the output of "mount"? Given your comments below and since cryptsetup can't seem to find the data, I would assume your data is gone. The XFS signature is a red herring caused by your extra step. Formatting them is wasted effort and can be confusing later, like now. The rest of the steps look ok.

On Sat, Jun 02, 2018 at 08:51:02PM -0500, page p wrote: tldr; what might save you is if you have a backup of your luks header. See further down here and the cryptsetup FAQ. Plus: I'd ask on the luks list for help. Meaning: you first created the raid, and then encrypted the drive. Right? And that probably was what shot luks: "mdadm --create" "create" means, according to man mdadm, you're writing "metadata (superblocks)" to the disk - it looks like a not so small write to a disk that already has data on it, among them the LUKS header (tho I cannot confirm the latter is at the same disk space as the the metadata are .. ) from the cryptsetup FAQ (probably on your system,too): * 5.7 Why is all my data permanently gone if I overwrite the LUKS header? Overwriting the LUKS header in part or in full is the most common reason why access to LUKS containers is lost permanently. Overwriting can be done in a number of fashions, like creating a new filesystem on the raw LUKS partition, making the raw partition part of a raid array and just writing to the raw partition. [ Looks you wrote to the raw partition. Later, same paragraph: ] If your LUKS container is still open, then it may be possible to extract the master key from the running system. See Item "How do I recover the master key from a mapped LUKS container?" in Section "Backup and Data Recovery". But let me guess: your luks container is closed now, and if yes, that option might be gone: But if you have a backup of your luks header that might help: Did you do something like this at some point: cryptsetup luksHeaderBackup --header-backup-file <file> <device> (See the mentioned luks FAQ under "6. Backup and Data Recovery") I cannot give you any hope that your data is recoverable, but you definitely should go the luks list and ask there about what happened, because if there's any chance for recovery of your data, it's most probably there: Archives: https://www.saout.de/pipermail/dm-crypt/ "If you want to subscribe just send an empty mail to dm-crypt-subscribe(a)saout.de.&quot; from: https://gitlab.com/cryptsetup/cryptsetup/wikis/home The archive, mentioned in the FAQ, seems being offline ... HTH Wolfgang