[dm-crypt] Protection against data failure

[dm-crypt] Protection against data failure

[Sun_Blood]

Hi DM-crypt

I have done some Googling and read your FAQ(great info) but I'm still
a bit confused so I hope somebody have time to answer a few questions.

I have recently started using dm-crypt and LVM finally taking a leap
in to the feature of disk handling. But now when I'm not using the
normal old partitions system with "one disk one partition" and the
disk itself are getting bigger there is a lot more data that could be
lost in a error. And with a big encrypted LVM I feel that some sort of
backups are necessary.

So how can I protect my self from loosing all my data? My system today
looks like this
sdb1 -> lvm -> dm_crypt -> filesystem
So by adding mirror raid I'm guessing that I protect my self from
hardware failure. sd[b-c]1 -> Raid -> LVM -> dm_crypt -> filysystem.
So far are I correct or am I missing something?

The above solution saves me from a broken disk but it can't protect me
from my self right(the biggest danger to a system: The user)? If I
accidental do a dd /dev/zero /dev/raid then all will be lost because
the raid will mirror even my mistakes?
Lucky I see that cryptsesetup has the luksHeaderBackup function. (LVM
also have a similar function).
My question here is if I accidental overwrite the first 5% of the disk
could I with this option restore and access the 95% rest of the system
data?
Or is this the wrong approach maybe a CoW setup would be the solution?

What I'm looking for is a way to protect the system from myself.
Hardware is one way and with that I can protect myself against
hardware failure good enough with raid and SMART disk.
But if I accidental overwrite the first part of the disk or some other
important part can I protect myself from that?

And I final question. The output from luksHeaderBackup how sensitive
is that information? Is it like handing somebody my password if I
store it on a local unencrypted disk?

Thanks in advance for any answers! =)
Martin

Re: [dm-crypt] Protection against data failure

[Milan Broz]

On 08/10/2011 10:14 AM, Sun_Blood wrote:

> Lucky I see that cryptsesetup has the luksHeaderBackup function. (LVM
> also have a similar function).
> My question here is if I accidental overwrite the first 5% of the disk
> could I with this option restore and access the 95% rest of the system
> data?

Just short answer: both (luksHeaderBackup for LUKS and vgcfgbackup for LVM)
create backup of _metadata_ not the data.

With these backups you are able to recover LVM over LUKS mappings.
Take is as backup of /etc with configuration of your system - it is good
idea to regularly backup system config.

But it says nothing about data on volumes itself. So it is obviously not replacement
for normal data backup, just prerequisite.

> And I final question. The output from luksHeaderBackup how sensitive
> is that information? Is it like handing somebody my password if I
> store it on a local unencrypted disk?

It is written in man page. To decrypt drive you need LUKS header (or backup
of it - even old with old keyslots) AND passhprase to some keyslot in it.

LUKS header backup is basically just image of start of the disk - you
can create similar backup using dd.

See http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#6._Backup_and_Data_Recovery

Milan

Re: [dm-crypt] Protection against data failure

[Marc Ballarin]

Hi,

> ...
> What I'm looking for is a way to protect the system from myself.
> Hardware is one way and with that I can protect myself against
> hardware failure good enough with raid and SMART disk.
> But if I accidental overwrite the first part of the disk or some other
> important part can I protect myself from that?

Just make complete backups. Instead of putting your second hard disk in a
mirror-RAID, put it in an eSATA or USB chassis or in some NAS device.

RAID-1 does not replace backups. Its primary purpose isn't even data safety
but high system availabilty - and unless you really need this, it is rather
pointless.
As you (unlike many others) recognized, you are the biggest danger yourself
and the only way to protect against this, is regular backups. Either
incremental/differential backups or - in my opinion ans experience much
preferable at home: simple backups in combination with some snapshotting
mechanism (LVM, btrfs, ZFS, ...).

(You can use snapshots at your backup source to get consistent data, but
also at the target to keep old versions.)

Simply encrypt your backup disk using its own LUKS header and don't even
bother with special header backups.

Regards,
Marc

Re: [dm-crypt] Protection against data failure

[Sun_Blood]

Thanks. That is a great idea. I was thinking on to advance solutions
to realize that what you say a secondary disk with its own LUKS header
and some crafty snapshot or normal backup procedure is probably the
easiest and best.

Thanks for all your answers. I feel I have a much clearer look on how
LUKS works(and some lvm too :-))

A final question that is more LVM but it sounds like you have some
knowledge in this area. My setup is LVM -> LUKS -> Filesystem.
If I use LVM snappshots on the LVM will the LUKS header also be
backuped because it's on top of LVM?

/Martin


On Wed, Aug 10, 2011 at 2:12 PM, Marc Ballarin <ballarin.marc@gmx.de> wrote:
> Hi,
>
>> ...
>> What I'm looking for is a way to protect the system from myself.
>> Hardware is one way and with that I can protect myself against
>> hardware failure good enough with raid and SMART disk.
>> But if I accidental overwrite the first part of the disk or some other
>> important part can I protect myself from that?
>
> Just make complete backups. Instead of putting your second hard disk in a
> mirror-RAID, put it in an eSATA or USB chassis or in some NAS device.
>
> RAID-1 does not replace backups. Its primary purpose isn't even data safety
> but high system availabilty - and unless you really need this, it is rather
> pointless.
> As you (unlike many others) recognized, you are the biggest danger yourself
> and the only way to protect against this, is regular backups. Either
> incremental/differential backups or - in my opinion ans experience much
> preferable at home: simple backups in combination with some snapshotting
> mechanism (LVM, btrfs, ZFS, ...).
>
> (You can use snapshots at your backup source to get consistent data, but
> also at the target to keep old versions.)
>
> Simply encrypt your backup disk using its own LUKS header and don't even
> bother with special header backups.
>
> Regards,
> Marc
>

Re: [dm-crypt] Protection against data failure

[Arno Wagner]

On Wed, Aug 10, 2011 at 10:14:37AM +0200, Sun_Blood wrote:
> Hi DM-crypt
> 
> I have done some Googling and read your FAQ(great info) but I'm still

Thanks!

> a bit confused so I hope somebody have time to answer a few questions.
> 
> I have recently started using dm-crypt and LVM finally taking a leap
> in to the feature of disk handling. But now when I'm not using the
> normal old partitions system with "one disk one partition" and the
> disk itself are getting bigger there is a lot more data that could be
> lost in a error. And with a big encrypted LVM I feel that some sort of
> backups are necessary.

Personally, I do not like LVM. I think in most situations it
complicates things without need. 
 
> So how can I protect my self from loosing all my data? My system today
> looks like this
> sdb1 -> lvm -> dm_crypt -> filesystem
> So by adding mirror raid I'm guessing that I protect my self from
> hardware failure. sd[b-c]1 -> Raid -> LVM -> dm_crypt -> filysystem.
> So far are I correct or am I missing something?

RAID1 protects you against disk failure, but you still need a 
backup, just as Milan says in his anzwer. 


> The above solution saves me from a broken disk but it can't protect me
> from my self right(the biggest danger to a system: The user)? If I

Indeed. Or two broken disks.

> accidental do a dd /dev/zero /dev/raid then all will be lost because
> the raid will mirror even my mistakes?

Faithfully, yes.

> Lucky I see that cryptsesetup has the luksHeaderBackup function. (LVM
> also have a similar function).
> My question here is if I accidental overwrite the first 5% of the disk
> could I with this option restore and access the 95% rest of the system
> data?

Depends on the filsyste, you have in there. Or the partitioning.

> Or is this the wrong approach maybe a CoW setup would be the solution?
> What I'm looking for is a way to protect the system from myself.
> Hardware is one way and with that I can protect myself against
> hardware failure good enough with raid and SMART disk.
> But if I accidental overwrite the first part of the disk or some other
> important part can I protect myself from that?

Backup on several (at least 3) media sets is the only good solution. 
And you are asking exactly the right questions.

> And I final question. The output from luksHeaderBackup how sensitive
> is that information? Is it like handing somebody my password if I
> store it on a local unencrypted disk?

It is like handing somebody your disks. Alls still protected.
Only potential problem is old passwords in the backup, see FAQ.

> Thanks in advance for any answers! =)

No Problem.
Arno

> Martin
> _______________________________________________
> dm-crypt mailing list

> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] Protection against data failure

[Marc Ballarin]

On Wed, 10 Aug 2011 14:44:38 +0200
Sun_Blood <sblood@gmail.com> wrote:

> ...
> 
> A final question that is more LVM but it sounds like you have some
> knowledge in this area. My setup is LVM -> LUKS -> Filesystem.
> If I use LVM snappshots on the LVM will the LUKS header also be
> backuped because it's on top of LVM?

That depends.

As an example:
Let's assume that /dev/mapper/sda is a linear mapping of /dev/sda.

cat /dev/zero > /dev/mapper/sda: snapshotting could preserve overwritten data
cat /dev/zero > /dev/sda: you are bypassing device mapper and overwritting
"form below" device mapper. So it can't do anything.

Snapshotting does not create physical copies of the snapshotted volume
automatically! Data will only be copied, if it is modified "from above" in
the original volume.

So, snapshotting is a very bad way to protect against accidental header
corruption and other forms of damage in lower levels. In general, snapshots
are no replacement for backups but can be a powerful addition.

Regards,
Marc