DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Milan Broz <gmazyland@gmail.com>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] LUKS backup headers for recovery
Date: Thu, 19 Jul 2012 23:36:59 +0200	[thread overview]
Message-ID: <50087DFB.1090000@gmail.com> (raw)
In-Reply-To: <20120719191822.GA20233@tansi.org>

On 07/19/2012 09:18 PM, Arno Wagner wrote:
> On Thu, Jul 19, 2012 at 11:36:53AM -0700, Two Spirit wrote:
>> I'm a heavy believer in the backup mantra "2 is 1 and 1 is none", and start
>> to feel comfortable when I have 3. Luckily I had backups to handle my
>> recent data loss with LUKS, but I had to suffer a long restore time as the
>> capacities get larger.

While it is simple from that mantra point of view, it complicates many other
things. People are resizing devices, if you place 2nd copy near the end of device,
you create many new problems.
I saw these problems in LVM, GPT an fake-raid metadata. If you have two versions,
which is more recent? Is it still valid if you completely remove one copy?
(Very common confusion - GPT reappears from backup copy.)
And you need atomic counter or timestamp (new LUKS format) and locking.

In enterprise environment you will need to use something better anyway,
(admin need to be able to provide you recovery passphrase), so you end with
a Key Escrow system. (https://fedorahosted.org/volume_key/ is the project based
on libcryptsetup for example).

Without this, you can either store backup of header, or you can print key
on paper and store it somewhere safely (see luksDump --dump-master-key)
with the same effect.

>> Since these are usually long running
>> file servers, I've found lots of discussions about passphrase recovery
>> while the systems are still running and not luksClosed). I did google
>> around for LUKS recovery procedures, but there were lots of bad long
>> involved processes out there that didn't work or I couldn't get to work.

And you are running file server without backup? Do you have backup of /etc?
So adding one 4M file (LUKS header with keyslots) into regular backup is easy.

People are usually highly stressed by situation (data gone and no backup).
And usually they lose ability to recover data not by initial mistake/error,
but by some stupid recovery action without real understanding what caused
the problem.

(And btw there is script in LUKS source recovering LUKS header from running dmcrypt
device, it is mentioned in FAQ... 

Ehm,... actually Arno forgot to update link, after git switch :)
It is here http://code.google.com/p/cryptsetup/source/browse/misc/luks-header-from-active

>> I now see the  luksHeaderBackup and luksHeaderRestore commands.(My excuse
>> is that I don't recall them when I first learned about cryptsetup many
>> years ago.) 

Because I added them later, exactly to simplify all these recovery problems.
You can even open device using backup file (without rewriting header).

>> Yes, I have seen a seasoned sysadmin run #rm -rf * from root on a
>> production server, so I could forsee someone doing something to 
>> mess up the LUKS headers.

There are two groups of people: one group run backups.
The second did not lost data yet :-)

Milan

  reply	other threads:[~2012-07-19 21:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-19 18:36 [dm-crypt] LUKS backup headers for recovery Two Spirit
2012-07-19 19:18 ` Arno Wagner
2012-07-19 21:36   ` Milan Broz [this message]
2012-07-19 23:27     ` Arno Wagner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50087DFB.1090000@gmail.com \
    --to=gmazyland@gmail.com \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox