I'd like to use BTRFS RAID1 with dm_crypt on a microserver. The hard part that I don't understand many things about how filesystems and LUKS work. Let's say we have 2 partitions on a drive and we do a whole drive encryption. Does that mean that both partitions will be encrypted and without knowing the key I won't be able to tell what filesystems they have? If so, then I don't understand how it is possible to have an unencrypted boot partition (necessary to load dm_crypt) on such drives or how btrfs raid1 will work if I encrypt both drives and they don't know from each other until both of them are decrypted? On the other hand if dm_crypt uses the btrfs partitions to store the data encrypted for example in a huge file, then wouldn't the btrfs scrub work on this huge file only and wouldn't a single uncorrectable error kill the whole content of the disks?
Does that mean that both partitions will be encrypted and without knowing the key I won't be able to tell what filesystems they have?
Yes, both partitions will be encrypted as LUKS partitions. You will be able to tell they are LUKS encrypted partitions. Without the key (and/or passphrase), you will not be able to tell what is inside the partition.
If so, then I don't understand how it is possible to have an unencrypted boot partition ...
Either (a) the boot partition is a separate [and unencrypted] partition, or (b) the boot loader [GRUB?] asks for the passphrase and knows how to decrypt and mount the boot parition. (I typically use an unencrypted boot partition with Ubuntu. I once saw an encrypted boot partition on an installation of Manjaro Linux.)
The main problem with this setup that since raid1 will be on the upper level, both hdds/ssds will be encrypted differently, which means performance penalty and a lot of unnecessary encryption.
I've heard the overhead of disk encryption is negligible. I have never had a problem with it. But then I have never measured the performance impact, and I do not need high speed disk IO on my system.
In any case, you will only pay the cost for multiple encryption when writing data. When reading, only one copy of the data will need to be read.
I use LUKS + ZFS + RAID1, but only for
/home. I use
(Note that if you have N>2 disks, BTRFS's "RAID1" mode is not really RAID1, as BTRFS will only create 2 copies of your data, not N copies as required by RAID1. In other words, BTRFS "RAID1" with N>2 disks gives you more storage space, not more redundancy.)
I read some texts in the topic. According to them the partitioning and formatting are separate processes, so I don't have to give the file system type by partitioning a block device (ssd/hdd/virtual?). The dm-crypt can convert an unencrypted block device to an encrypted one by encrypting each block (or sector?) individually and the btrfs can live on that encrypted block device.
Note: dmcrypt + btrfs needs 4+ kernel to work properly; 3.2- kernels have compatibility and security issues, 4.0- kernels have performance issues.
The main problem with this setup that since raid1 will be on the upper level, both hdds/ssds will be encrypted differently, which means performance penalty and a lot of unnecessary encryption. According to other texts/answers I read there is no way to do this now. People are working on btrfs encryption, but there is nothing stable yet. Currently the stacked approach with ecryptfs - the btrfs FAQ mentions - is a lot slower than dm-crypt, so that wouldn't be a good solution either. Another option is using zfs, which has encryption support, but afaik. it consumes a lot of memory compared to btrfs.
update (Jan, 2019):
I checked zfs too, it has a nice native encryption and you can encrypt the swap partition too, so I think that is the way to go. It has some drawbacks too, it uses more memory and it isn't as straightforward to add a new disk as with btrfs.
perhaps I'm miss-understanding your question, but this should be completely fine.
The prerequisite for your system is that the LUKS devices are opened/decrypted prior to accessing them. Two basic ways this could be set up:
- on a filesystem required for boot: you had to enter your
passphraseat boot (
grub, or kernel depending on whether you fully FDE'd your disk)
- this would have a
0for mount order in
- this would have a
- or not required for boot, eg a data drive.
- I'll use this as an example; it's the slightly more complicated case it would seem.
assume for exmaple you have a non-encrypted
/dev/sda1 and LUKS encrypted
So you need all relevant devices
decrypted. This is a completely independent step / entity from BTRFS. LUKS uses the kernel device-mapper, so what this means is:
LUKS, you'd reference your btrfs filesystem via the standard device path do your partition such as
/dev/sda1(note, we're talking partition not whole
sdadrive, since the filesystem is contained there).
LUKS, luks conceptually wraps the filesystem. When you (manually, or eg automated at boot)
luksOpenit (again, kernel
devicemapperis used) you end up with a
/dev/mapper/your_label. You do still have the normal
/dev/sda1node, but this isn't going to be used; the
dev/mapper/node is (after luks-open) conceptually the same as the
/dev/sda1- it's where your btrfs filesystem is.
Once you have the
btrfs filesystems available, eg
/dev/mapper/your_label etc, you can perform whatever
btrfs tasks you need, such as
device add to make a
Now - how to "make the
btrfs filesystem available automatically?
- you can manually unlock it of course
- your LUKS can be the one that contains your root fs, meaning you would have had to follow other guides to have
grubor the kernel in your
- you have a secure filesystem already unlocked (eg, your root FS) and we can use a
/etc/crypttabto unlock it automatically.
using the last as an example, as it seems like the case you're asking about
- create a
keyfileand add associate it with the drive via
cryptsetup luksAddKey /dev/sdb1(prompts you for your LUKS passphrase) - many tutorials for this online, such as https://access.redhat.com/solutions/230993
- create an entry in
/etc/crypttabthat tells your system to mount that device (note, use a
/dev/sdb1... but that's another topic!). The keyfile, now available since your root fs was previously
luksOpened, is used automatically to open it.
btrfs filesystems are available / decrypted, and will work just as though LUKS isn't present (albeit at
/dev/mapper/... nodes, not