Btrfs guide to set up an LUKS-encrypted btrfs raid volume with included maintenance & recovery guide

btrfs-guide.md

Encrypted Btrfs storage setup and maintenance guide

Initial setup with LUKS/dm-crypt

This exemplary initial setup uses two devices /dev/sdb and /dev/sdc but can be applied to any amount of devices by following the steps with additional devices.

Create keyfile:

dd bs=64 count=1 if=/dev/urandom of=/etc/cryptkey iflag=fullblock
chmod 600 /etc/cryptkey

Encrypt devices:

cryptsetup -v -c aes-xts-plain64 -h sha512 -s 512 luksFormat /dev/sdb /etc/cryptkey
cryptsetup -v -c aes-xts-plain64 -h sha512 -s 512 luksFormat /dev/sdc /etc/cryptkey

Backup LUKS header:

cryptsetup luksHeaderBackup --header-backup-file ~/sdb.header.bak /dev/sdb
cryptsetup luksHeaderBackup --header-backup-file ~/sdc.header.bak /dev/sdc

Automatically unlock LUKS devices on boot by editing /etc/crypttab:

data1 UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /etc/cryptkey luks,noearly #,discard (for SSDs)
data2 UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /etc/cryptkey luks,noearly #,discard (for SSDs)
# Use 'blkid /dev/sdb' to get the UUID

Unlock encrypted devices now to create the filesystem in next step:

cryptsetup open --key-file=/etc/cryptkey --type luks /dev/sdb data1
cryptsetup open --key-file=/etc/cryptkey --type luks /dev/sdc data2

Create filesystem:

mkfs.btrfs -m raid1 -d raid1 /dev/mapper/data1 /dev/mapper/data2

Mount filesystem:

mount -t btrfs -o defaults,noatime,compress=zstd /dev/mapper/data1 /mnt/data

Automatically mount btrfs filesystem on boot by editing /etc/fstab:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/data btrfs defaults,noatime,compress=zstd 0 2
# Add option 'autodefrag' to allow automatic defragmentation: useful for files with lot of random writes like databases or virtual machine images
# Use 'blkid /dev/mapper/data1' to get the UUID of the Btrfs partition, it is common for all raid devices

Maintenance

In a btrfs raid setup it is necessary to frequently run a btrfs scrub to check for corrupted blocks/flipped bits and repair them using a healthy copy from one of the mirror disks.

In the example below a systemd-timer is used to run an automatic btrfs scrub job each month.

/etc/systemd/system/btrfs-scrub.timer:

[Unit]
Description=Monthly scrub btrfs filesystem, verify block checksums
Documentation=man:btrfs-scrub

[Timer]
# first saturday each month
OnCalendar=Sat *-*-1..7 3:00:00
RandomizedDelaySec=10min

[Install]
WantedBy=timers.target

/etc/systemd/system/btrfs-scrub.service:

[Unit]
Description=Scrub btrfs filesystem, verify block checksums
Documentation=man:btrfs-scrub

[Service]
Type=simple
ExecStart=/bin/btrfs scrub start -Bd /mnt/data
KillSignal=SIGINT
IOSchedulingClass=idle
CPUSchedulingPolicy=idle

Recovery from device failure

Example with one failed device:

• /dev/mapper/data1 working device
• /dev/mapper/data2 failed device
• /dev/mapper/data3 new device
• /mnt/data mountpoint

In case of failing/failed device, mount in degraded mode with one of the working devices:

mount -t btrfs -o defaults,noatime,compress=zstd,degraded /dev/mapper/data1 /mnt/data

Find the the device ID of the missing disk by executing btrfs device usage /mnt/data:

# btrfs device usage /mnt/data

/dev/mapper/data1, ID: 1
   Device size:             7.28TiB
   Device slack:              0.00B
   Data,RAID1:              5.46TiB
   Metadata,RAID1:          7.00GiB
   System,RAID1:           32.00MiB
   Unallocated:             1.81TiB

missing, ID: 2
   Device size:             7.28TiB
   Device slack:              0.00B
   Data,RAID1:              5.46TiB
   Metadata,RAID1:          7.00GiB
   System,RAID1:           32.00MiB
   Unallocated:             1.81TiB

NOTE: Encrypt the new device before using it in the btrfs raid by following the steps above.

Start the replace operation in background by adding the new device to the btrfs raid using the device ID of the missing disk:

btrfs replace start 2 /dev/mapper/data3 /mnt/data

(Optional) Check the replace progress:

btrfs replace status /mnt/data

Once the replace operation has finished, the fstab entry is left unmodified:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/data btrfs defaults,noatime,compress=zstd 0 2
# Use 'blkid /dev/mapper/data1' to get the UUID of the Btrfs partition, it is common for all raid devices

this is excellent! Kudos!

Super helpful, thank you!

Amazing, thanks a lot!

Where does GRUB fit into this? I see no grub-install command.

Where does GRUB fit into this? I see no grub-install command.

Hello @iio7, this is not guide which uses Btrfs on the system partition, so there's no need for a bootloader like grub. Btrfs here is used as data partition on separate disks, e.g. a NAS. Furthermore I wouldn't recommend using Btrfs configured as RAID1 as system partition. When one disk fails, your system won't boot anymore, unlike ZFS which automatically boots in degraded mode, but Btrfs unfortunately does not.

Hello @iio7, this is not guide which uses Btrfs on the system partition, so there's no need for a bootloader like grub. Btrfs here is used as data partition on separate disks, e.g. a NAS. Furthermore I wouldn't recommend using Btrfs configured as RAID1 as system partition. When one disk fails, your system won't boot anymore, unlike ZFS which automatically boots in degraded mode, but Btrfs unfortunately does not.

Thank you very much for your reply, I didn't know about Btrfs not booting in a degraded mode!

Thank you very much for your reply, I didn't know about Btrfs not booting in a degraded mode!

Well, it's not automatic or default for any distro I know of. So if you go into the recovery process and replace one of the Raid boot disks, the system won't boot anymore. Here is the description of the bug and a possible workaround: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229456

Well, it's not automatic or default for any distro I know of. So if you go into the recovery process and replace one of the Raid boot disks, the system won't boot anymore. Here is the description of the bug and a possible workaround: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229456

I found that kernel argument after looking into the issue. Thanks.

https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices#Replacing_failed_devices

Seems like there's an easier way to replace a missing/failed device with btrfs device replace, which, according to anecdotal evidence on forum/reddit threads, might be a bit more expedient than the add+delete approach.

And another moment: i would still recommend mounting by UUID in the fstab rather than by the mapper name, for the sake of stability (say, one of those drives fails, you replace it and give the replacement next integer increment in the name... but the failed drive was the one whose name you have used in the fstab). You can get the btrfs UUID (it's shared across all of the partitions in the array) by using the blkid after any (you don't even need to unlock all of them) of the crypt devices is unlocked:

# blkid | sort
/dev/mapper/crypt_data_001: UUID="a9df909a-5fe8-47ae-be09-7c443d96e558" UUID_SUB="d7da35bd-1c61-4748-8696-70988077172a" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/mapper/crypt_data_002: UUID="a9df909a-5fe8-47ae-be09-7c443d96e558" UUID_SUB="9a93e5f7-464b-4142-8656-818270925eeb" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/mapper/crypt_data_003: UUID="a9df909a-5fe8-47ae-be09-7c443d96e558" UUID_SUB="b9898e5c-7999-4c22-951c-5edf4ffaa5cb" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/sda: UUID="f98349d1-f8a7-4383-bc23-2e6a80315c6b" TYPE="crypto_LUKS"
/dev/sdb: UUID="dea5e4a7-20aa-456f-807a-81c62a0e5c0c" TYPE="crypto_LUKS"
/dev/sdc: UUID="3c60817c-3285-4cd6-8bee-3de7799221cd" TYPE="crypto_LUKS"

so your fstab should look like

UUID=a9df909a-5fe8-47ae-be09-7c443d96e558 /mnt/data btrfs defaults,noatime,compress=zstd 0 2

@NekoiNemo Thank you. I updated the section Recovery from device failure with the btrfs replace command and edited the fstab examples according to your suggestions. It definitely makes sense to use the common btrfs partition id.

Resolved the issue. The /etc/crypttab file had the incorrect SELinux policy

Thanks @MaxXor this is an amazing guide.

I'm trying to move my btrfs disks to a new OS, starting fresh after a couple of years. I've retraced these steps and running cryptsetup open --key-file=/etc/cryptkey --type luks /dev/sdb data1 works and I can then run mount -a and everything is in /mnt/data. However, when I try and reboot, it seems that the volumes don't get decrypted and then fstab fails. Any idea how I can test/debug crypttab?

@FrankelJb Thanks for your feedback! :)

Can you show your /etc/crypttab content?

Thanks for the guide. I just don't understand the reason to have an encrypted storage when your encryption key is located on the same system, everyone gaining physical or remote access to it will also have access to the encryption key and to the data stored in your btrfs filesystem. So what good is it configured like this?

It depends on what you want to protect from. If someone has remote ROOT access to your machine to read the encryption key (which is hopefully stored as 400/600 root-owned file)... You have other problems to worry about. Meanwhile this method allows you to enter the pass by hand once on boot to unlock the system disk, and then use the encryption keys stored on it to unlock all of the rest of your disks

Thanks for the guide. I just don't understand the reason to have an encrypted storage when your encryption key is located on the same system, everyone gaining physical or remote access to it will also have access to the encryption key and to the data stored in your btrfs filesystem. So what good is it configured like this?

The assumption is that your OS is already encrypted in a different partition. The encryption of the OS partition is not explained in this guide and probably out of scope.

If you still want to encrypt your data and are unable for any reason to encrypt your OS partition, maybe you can set pass-phrases instead of cryptkey. By doing this, you will have to manually enter the pass-phrase every time you reboot the system. (Please take this with a grain of salt, I am no expert, this might not be as secure)

@phalaaxx I assume that you are already using an encrypted system partition. That part is covered in all installers of common distributions such as Ubutnu, Debian, etc. so I won't go into detail here. It's more about securely adding additional storage, which when powered off can't be accessed by any means. Remote root access to your machine is indeed a worst-case scenario and this guide is not meant to protect your data from such attacks.

@phalaaxx I assume that you are already using an encrypted system partition. That part is covered in all installers of common distributions such as Ubutnu, Debian, etc. so I won't go into detail here. It's more about securely adding additional storage, which when powered off can't be accessed by any means. Remote root access to your machine is indeed a worst-case scenario and this guide is not meant to protect your data from such attacks.

That makes sense, thank you.
(Also thanks to @george-andrei and @NekoiNemo)

Hi