Re: Encrypt underlying disks after the fact?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@xxxxxxxxxxx
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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux