From: Laurence Darby <ldarby@tuffmail.com>
To: Arno Wagner <arno@wagner.name>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] Encrypted Raid1 or Raid 1 of encrypted devices?
Date: Wed, 13 Jul 2011 00:14:04 +0100 [thread overview]
Message-ID: <20110713001404.06d40836.ldarby@tuffmail.com> (raw)
In-Reply-To: <20110712123132.GB31326@tansi.org>
Hi Arno, All,
Thanks very much for your comments, I'll definitely go with encrypting
the RAID.
Arno Wagner wrote:
> On Tue, Jul 12, 2011 at 02:10:03PM +0200, Milan Broz wrote:
> > On 07/12/2011 01:32 PM, Jorge F?bregas wrote:
> > > That's an interesting question: encrypted raid1 or raid1 of
> > > encrypted disks? That also could be phrased as "dm-crypt on top
> > > of dm-raid" or "dm-raid on top of dm-crypt"?
> > >
> > > I must admit I would have never thought about a "raid1 of
> > > encrypted disks" (seems awkward) but apparently it works. I'm
> > > new here (and to disk encryption at all) but here are my two
> > > cents:
> >
> > Technically both works.
>
> Technically, RAID and encryption are on the same layer of the
> storage system and you can do arbitrary conbinations.
>
> > > # Performance
> > > I guess from the point of view of performance (CPU-wise) , an
> > > "encrypted RAID1" would be better as you would be only encrypting
> > > once and DM-raid will take care of copying those bits as they are
> > > to the 2nd disk. I suggest you do some tests (copying large
> > > amount of data to the encrypted disk) and measure it.
> >
> > This depends on kernel version and if the system is SMP/multi-cpu.
> > For <2.6.38 you may get better performance for raid over crypt,
> > for newer kernel it will be different.
> > (I am not saying better because there are still performance issues
> > with crypt over MD Raid. Depends on io pattern and if IO are issued
> > from different cpus or not. Like dd can be slower but threaded fs
> > test can have much more better performance.)
> >
Yes, I noticed this - a single dd process has to wait for both the
encryption and then IO, so more processes are needed to fill the
pipeline.
There's not much of a performance difference anyway - I have a 2 core
machine, and found that both disks (loopback files) got encrypted at
the same time (top showed 2 kworker processes, each using 80% cpu, the
rest mostly waiting on IO.)
> > > # Management
> > > There's no doubt that an encrypted raid1 is much better (much less
> > > commands: you just need to format once, luksOpen once, luksClose
> > > once. one backup of the header)
> >
> > yes, I would suggest crypt over MD always too.
>
> Good point. And you ned to enter your passphrase twice, exposing
> it more.
>
> The main difference security-wise is that an attacker gets
> the same data-set encrypted with two different keys when
> RAIDing encrypted devices. That can be a concern.
>
>
Thank you for pointing that out - it's exactly the kind of thing I
wasn't aware of but should be.
> > > # Reliability
> > > I'm not sure about this part. Let's see what others have to say
> > > regarding this.
> >
> > IMHO both solutions are similar here. Some errors are propagated,
> > hw failure (RAM, disk) would have similar effect.
>
> Reliability with regard to data corryption really belongs into
> the filesystem-layer and above and into the hysocal device layer.
>
> RAID seems to be reliability, but in fact it is redundancy
> only, and detection of errors (bit errors, unreadable sectors
> and dead disks) is done below (or for bit-errors possibly
> in the filesystem-layer with a checksumming FS). The RAID
> cannot detect errors, it can just react to errors reported by
> lower layers using the redundancy it provides.
> One exception: It can do consistency checks, but it can only
> do somethign about inconsistencioes if it is at least 3-way
> redundant by voting, i.e. >= 3-way RAID1 or RAID6. And consistency
> checks are not a normal RAID operation, but rather an externally
> triggered RAID maintenance operation.
>
> > RAID is not backup. You should backup LUKS header and data anyway.
>
This RAID1 is my backup device, that I do daily rsync-snapshots to.
I'll admit, I'm not doing automated integrity checks yet, I know I
should be, but encryption is more fun :)
I was thinking that with a RAID of encrypted devices, rather than the
encrypted RAID, that I wouldn't need a header backup - If I break one,
that mistake isn't immediately written to both drives, so I can just
reformat it, and rebuild the array. Although, yes, just restoring a
header backup does sound a lot easier, and after what Arno said above,
it's not feasible anyway.
I'll reply to the other thread tomorrow, bedtime now.
Thanks,
Laurence
next prev parent reply other threads:[~2011-07-12 23:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-11 22:03 [dm-crypt] Encrypted Raid1 or Raid 1 of encrypted devices? Laurence Darby
2011-07-12 11:32 ` Jorge Fábregas
2011-07-12 12:10 ` Milan Broz
2011-07-12 12:31 ` Arno Wagner
2011-07-12 23:14 ` Laurence Darby [this message]
2011-07-12 12:20 ` Arno Wagner
[not found] <mailman.6.1310512453.3639.dm-crypt@saout.de>
2011-07-14 6:17 ` Yaron Sheffer
2011-07-14 11:01 ` Arno Wagner
2011-07-14 11:41 ` Roscoe
2011-07-14 13:42 ` 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=20110713001404.06d40836.ldarby@tuffmail.com \
--to=ldarby@tuffmail.com \
--cc=arno@wagner.name \
--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