Hi Arno,
thanks for answering. I created the partition table within /dev/md2 and
the raid is still working.
My current last hope is that the salt might be in a redundant part of
the raid array. Currently I grep the single devices for the LUKS-header
file like this:
grep -a -b -P --only-matching 'LUKS\xba\xbe' /dev/sdc
grep -a -b -P --only-matching 'LUKS\xba\xbe' /dev/sdb
grep -a -b -P --only-matching 'LUKS\xba\xbe' /dev/sdd
Could that be successful?
However here is also my mdadm --detail:
/dev/md2:
Version : 1.2
Creation Time : Thu Jan 3 21:43:32 2013
Raid Level : raid5
Array Size : 3906763776 (3725.78 GiB 4000.53 GB)
Used Dev Size : 1953381888 (1862.89 GiB 2000.26 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Fri Jul 1 13:02:14 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : braegel1:2 (local to host braegel1)
UUID : 54ee60b5:45837e78:661fa3ed:3eacb88f
Events : 44120
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
3 8 49 2 active sync /dev/sdd1
Regards,
Bernd
Am 2. Juli 2016 12:25:17 MESZ, schrieb Arno Wagner <arno@xxxxxxxxxxx>:
>Ah, sorry, I am confused. The first question is whether
>you killed the RAID as well or whether you created the
>msdos partition table within /dev/md2. In the latter
>case we do not need the RAID info.
>
>Regards,
>Arno
>
>On Sat, Jul 02, 2016 at 12:20:00 CEST, Arno Wagner wrote:
>> Hi Bernd,
>>
>> data-recovery for this is typically relatively easy or completely
>> impossible. To determine which it is, we need to find out what
>> happened exactly. The only really irreplaceable values in the header
>> are the salts (see FAQ Item 6.12). These are not secret, but
>> each is 256 bits of crypto-grade randomness and they cannot
>> be reconstructed or guessed.
>>
>> The first question is what was overwritten by that partition
>> sector. Traditionally, Linux software RAID has the RAID superblock
>> at the end, but unfortunately some people "improved" this, so
>> it can now be at the end, at the start and at 4kB from the start.
>>
>> This is relevant becauese it influences the data offset, i.e.
>> the place where the LUKS header is put.
>>
>> Hence we need the output of
>>
>> mdadm --detail /dev/md2
>>
>> whichs dumps the RAID metadata.
>>
>> Regards,
>> Arno
>>
>>
>> On Sat, Jul 02, 2016 at 08:33:09 CEST, Bernd Brägelmann wrote:
>> > Hi there,
>> >
>> > i think i destroyed my luks data.
>> >
>> > I accidentally created a msdos partition table on the luks device.
>I
>> > think the device was not partitioned. The device is a raid5 mdadm
>at
>> > /dev/md2.
>> >
>> > Now i cannot luksOpen the device anymore.
>> >
>> > I already try to hexdump|grep for the LUKS header but until now i
>> > haven't found it. In the Luks-FAQ 6.1 the problem is described as a
>> > common user error and it is very common that the partitioning has
>> > destroyed the LUKS header.
>> >
>> > My question is: Is my data destroyed beyond recovery? It would
>really
>> > help me to cope with this. Is it possible to "manually" fix a
>partially
>> > destroyed LUKS header? Are there other ways to recover the data? I
>would
>> > gladly pay for a recovery solution.
>> >
>> > Regards,
>> >
>> > Bernd
>> >
>> > --
>> > Bernd Brägelmann - FA für Radiologie
>> > Robert-Koch-Straße 42 28277 Bremen
>> > www.berndbraegelmann.de +4915141457796
>> > _______________________________________________
>> > dm-crypt mailing list
>> > dm-crypt@xxxxxxxx
>> > http://www.saout.de/mailman/listinfo/dm-crypt
>>
>> --
>> Arno Wagner, Dr. sc. techn., Dipl. Inform., Email:
>arno@xxxxxxxxxxx
>> GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1
>CB5D 9718
>> ----
>> A good decision is based on knowledge and not on numbers. -- Plato
>>
>> 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
>
>--
>Arno Wagner, Dr. sc. techn., Dipl. Inform., Email:
>arno@xxxxxxxxxxx
>GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D
>9718
>----
>A good decision is based on knowledge and not on numbers. -- Plato
>
>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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
