Adding encryption to existing software RAID-mirrored volume

Question

I currently have a server which has a number of LVM volumes using software RAID for mirroring. Something like this:

sdd                        8:48   0 894.3G  0 disk  
└─sdd1                     8:49   0 465.8G  0 part  
  └─md4                    9:4    0 465.8G  0 raid1 /myfiles
sdc                        8:32   0 894.3G  0 disk  
└─sdc1                     8:33   0 894.3G  0 part  
  └─md4                    9:4    0 465.8G  0 raid1 /myfiles

Actually, now that I look at that, I think LVM isn't in the picture since I don't see any (dm-X) devices mentioned. :( I am using LVM for /home but not / and /boot

Is there a way to slide-in an encryption layer (e.g. dm-crypt) between the layers that comprise my /myfiles filesystem? Or would I have to create a new set of partitions/devices using LVM and copy everything over?

In the past, I've migrated physical disks with zero downtime by breaking the RAID, swapping e.g. sdc with a new disk, then letting the RAID system re-sync, then repeating the process with sdd. Is it possible to prepare an encrypted volume underneath the RAID and use the same technique? Or do I have to switch to an LVM-managed volume in order to use e.g. dm-crypt for that kind of thing?

I'm running a Linux 3.2 kernel and an ext4 filesystem in this particular case, so I can't just enable ext4 crypto.

Answer 1

Disk encryption with dm-crypt takes a block device and spits out a block device. It doesn't depend on LVM; you set it up with cryptsetup (typically) or dmsetup.

The only problem you may face with inserting an encryption layer is that the normal way to do it uses a LUKS header, which eats a small amount of disk space. That means your encrypted block device will be slightly smaller than your original one. That might make re-adding it to the RAID array fail (depending on how much unused space the RAID layout has).

Of course, if you make a new slightly smaller array, and a new slightly smaller filesystem on it, you could copy the data over—though that'd likely require downtime.