[dm-crypt] Encrypt underlying disks after the fact?

Omen Wild omen.wild at gmail.com
Wed Apr 3 06:13:18 CEST 2013


Quoting Arno Wagner <arno at wagner.name> on Tue, Apr 02 02:39:
>
> With enought space, this should work. However if you encrypt the
> underlying disks, you will have to unlock each one individually
> or script something before mounting.

Good point. I would probably use the same passphrase on both to make
booting easier.

> Integrating RAID into the filesystem like ZFS does really is not that
> good an idea and this is one eaxmple why: It breaks the layering and
> the filesystem has to suddenly do everything, including encryption. Not
> good as it violates KISS. Sadly, the BTRFS developers are making the
> same mistake...

I use to totally agree with this, then I started using ZFS at work and
liked it so much I'm using it a home with the (slightly) experimental
ZFS on Linux.

> Detached header would mean you have one more device to worry about.
> I would recommend avoiding it in this scenario.

True. It was a question that came up browsing the docs. I was thinking a
header backup to an encrypted file stored on several CDs stored in
different places would help offset that. Mostly I'm trying to figure out
how to do this without completely wiping and restoring the data.

> Your device is only 2TB, are you sure you want ZFS on top of that?

You better believe it. Those 2TB contain all of my important data:
photos, video clips, email, scripts and configuration I've been
perfecting since starting with UNIX. Even though I'm using mirrored disks
I have still have still set /home dataset to have 2 copies, so all of the
really important data is actually on disk 4 times. Since this is only
15GB of space I feel the duplication is worth the space. Paranoid, yes.
Overly paranoid, I don't think so.

> Also, AFAIK, ZFS is Beta-quality on Linux and incomplete.

Sort of, but it's pretty solid, and it was mature on Solaris before they
started the integration so the foundation is really, really solid.

> You could also do something else if it does not fit or if you
> want to change thesize anyways:
> 
> 1. Make a degraded md RAID1 on a new disk.
> 2. Put a LUKS container on it
> 3. Put ZFS (single drive) on top of that
> 4. Copy all data over
> 5. Remove one disk from the SFS tool and add it to the md RAID1.

You lose one of the really neat features of ZFS doing it this way, the
ability to detect corruption via checksums and re-read from the other
disk (which is really unlikely to have corruption in the same file).
It then re-writes clean data to the previously broken mirror so you
have 2 clean copies of the data again.

-- 
Help fight continental drift.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4270 bytes
Desc: not available
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20130402/594cd2cf/attachment.bin>


More information about the dm-crypt mailing list