Re: [dm-crypt] LUKS backup headers for recovery

[Arno Wagner <arno@wagner.name>]

On Thu, Jul 19, 2012 at 11:36:59PM +0200, Milan Broz wrote:
> 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.

Very true. A relatively simple implementation goes to 
a complex one with surprising behaviour. Not good. 
KISS is still the prime directive for any good engineer.

> 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.

And if you do that make sure to dump all the parameters as well.
cryptsetup is conservative about changing defaults, but it can
happen.
 
> >> 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.

Indeed. I have added a note for this at the start of the FAQ.
 
> (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

Wups. Fixed.
 
> >> 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).

Which is a very good thing, as any write has a chance of doing more 
damage.

> >> 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 :-)

Hehehehe, yes. Makes me remember the first (and only) 
time I lost important data. The universe looks a bit 
different after that experience ;-)

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
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