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

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

[Omen Wild]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

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

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.

Oh, and backups, backups, and more backups.

Thanks

-- 
The world is coming to an end, SAVE YOUR BUFFERS!!!

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4270 bytes --]

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

[Arno Wagner]

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

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

[Omen Wild]

[-- Attachment #1: Type: text/plain, Size: 2638 bytes --]

Quoting Arno Wagner <arno@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.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4270 bytes --]