From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Encrypt underlying disks after the fact?
Date: Tue, 2 Apr 2013 02:39:29 +0200 [thread overview]
Message-ID: <20130402003929.GA21628@tansi.org> (raw)
In-Reply-To: <20130401232528.GB10159@mandarb.com>
On Mon, Apr 01, 2013 at 04:25:28PM -0700, Omen Wild wrote:
> I have a mirrored ZFS on Linux pool and I am now regretting not having
> encrypted the underlying disks. Can I do this after the fact, i.e.:
>
> - break the mirror: zpool detach tank /dev/sdb
> - wipe disk
> - cryptsetup luksFormat /dev/sdb
> - rebuild the mirror: zpool attach tank /dev/sda /dev/mapper/c1
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. 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...
> When I created the pool I gave ZFS the entire disks so it formatted them
> GPT:
>
> ----- Begin quote -----
> Partition Table: gpt
>
> Number Start End Size File system Name Flags
> 1 1048576B 2000390528511B 2000389479936B zfs zfs
> 9 2000390528512B 2000398917119B 8388608B
> ----- End quote -----
>
> The main question is whether the LUKS disk would have at least as many
> blocks as #1. Looking at the numbers is looks like there is 1MB
> available at the beginning, and 8MB at the end, and the LUKS header is
> 1MB+4096B or 2 MB, so it looks like it will fit on the raw device. The
> other route would be to use a detached header. Any recommendations
> between the two methods?
Detached header would mean you have one more device to worry about.
I would recommend avoiding it in this scenario. Your device is
only 2TB, are you sure you want ZFS on top of that? Also, AFAIK,
ZFS is Beta-quality on Linux and incomplete.
> Assuming this could work I suppose the safest way to do this would be to
> buy a 3rd disk, encrypt it, add it to the pool, then rotate the original
> 2 out one at a time.
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.
This gives you proper layering again and you have to do only one
unlock on mounting.
> Oh, and backups, backups, and more backups.
Indeed.
Arno
> Thanks
>
> --
> The world is coming to an end, SAVE YOUR BUFFERS!!!
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
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
next prev parent reply other threads:[~2013-04-02 0:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-01 23:25 [dm-crypt] Encrypt underlying disks after the fact? Omen Wild
2013-04-02 0:39 ` Arno Wagner [this message]
2013-04-03 4:13 ` Omen Wild
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=20130402003929.GA21628@tansi.org \
--to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.