[dm-crypt] Open raid1 with luks encryption after a raid re-create
l-alexandre at sapo.pt
Tue Nov 24 12:15:18 CET 2015
Dear Arno and Sven,
Thanks very much for your support.
I was able to open the copy I made with
tail -c +135266305 /dev/sdx > /dev/sdy
cryptsetup luksOpen /dev/sdy e1
and have all my data back.
Thanks again for your support.
On 23-11-2015 06:26, Arno Wagner wrote:
> On Mon, Nov 23, 2015 at 04:56:34 CET, Sven Eschenberg wrote:
>> Am 23.11.2015 um 04:35 schrieb Arno Wagner:
>>> On Sun, Nov 22, 2015 at 23:30:23 CET, Sven Eschenberg wrote:
>>>> Now to your question, once you know the offset of the header:
>>>> 1.)Setup a loop device from your image (You can use an offset into
>>>> the image where your loop device starts with sector 0) see --offset
>>>> in losetup man page.
>>> Ah, yes. That would save copying it.
>> That was the plan. In general using dmsetup to create a mapping
>> manually should work too, if loop device support is missing -
>> dmsetup is pretty cryptic to use though.
> "Cryptic" is not good here...
> I was not aware that losetup allows read-only mappings, or I
> would probably have looked at it too.
> Excellent! So I learned something too!
>>>> Inspect loopdevice if the LUKS Header now is on sector 0
>>>> 2.)Try a cryptsetup luksopen in readonly mode
>>> Good idea. With that it may be reasonaly safe to work
>>> with the original disk. I still would make a full
>>> backup before.
>> Well, I thought about using the loop on the file while the physical
>> disk stays unchanged. Otherwise it would be possible to work on the
>> physical disk, and keep a safety image. No matter which way one
>> chooses, always have a safety copy.
>> If the disk is having mechanical problems or something similiar one
>> would of course use 2 images, one 'master binary backup' and the
>> replica to work on.
>> Once mapping and opening works, one can choose to either copy out
>> the files and backup (usually a good idea) or to create a copy in
>> the manner you described. Possibly such an image could then be
>> remerged onto a new clean array, if it is otherwise intact. Not
>> without some remaining risks though.
> Indeed. And first things first, lets see whether that header is
> viable before goping any further.
More information about the dm-crypt