I have a btrfs raid1 composed of two entire, large harddisks of the same size. Now I would like to migrate the data to a btrfs raid1 composed of two encrypted luks-devices on the same harddisks. I have separate copies of the data on other boxes as a backup. My plan is to remove one device from the raid1, create a luks volume on the removed device, create a btrfs filesystem on the luks device, copy the data onto the new device, create a luks volume on the second device and add the second device to the encrypted btrfs system.

Does this sound reasonable and does anyone have a recipe for that? Or should I better buy a third harddisk for the migration?

1 Answer 1


To answer my own question I have made the following experiment on a spare hard disk. Be sure to have a valid and restorable backup. These commands can irretrievably destroy valuable data if e.g. applied to the wrong device.

Creating the test system

First we need two partitions to work with, I created them with fdisk to get:

Device     Boot    Start      End  Sectors Size Id Type
/dev/sda1           2048 20973567 20971520  10G 83 Linux
/dev/sda2       20973568 41945087 20971520  10G 83 Linux

Then I created an unencrypted btrfs raid1 (you need to force with -f if the partitions are used, but be sure you know what you are doing):

> mkfs.btrfs -m raid1 -d raid1 /dev/sda1 /dev/sda2


   ID        SIZE  PATH
    1    10.00GiB  /dev/sda1
    2    10.00GiB  /dev/sda2

Then I mounted the filesystem to have a live system to work with, and created a test file:

> mount /dev/sda1 /mnt/tmp
> echo "Hello World" > /mnt/tmp/hello.txt

Doing the migration

First resize the filesystem so we can later replace the devices with the smaller encrypted versions.

> btrfs fi resize 1:9G /mnt/tmp
> btrfs fi resize 2:9G /mnt/tmp

Then we remove the duplication in the system (needs to be forced because it increases the risk of data loss). This takes a long time on a large file system, as it rewrites all the data. We can check the progress with btrfs balance status /mnt/tmp.

> btrfs balance start -mconvert=single -dconvert=single /mnt/tmp --force
Done, had to relocate 3 out of 3 chunks

Then we can remove one of the devices. If this takes long, we can check the status using btrfs device usage /mnt/tmp.

> btrfs device remove 1 /mnt/tmp
> btrfs device usage /mnt/tmp
/dev/sda2, ID: 2
   Device size:            10.00GiB
   Device slack:            1.00GiB
   Data,single:             1.00GiB
   Metadata,single:       256.00MiB
   System,single:          32.00MiB
   Unallocated:             7.72GiB

Then we convert it to a LUKS device

> cryptsetup luksFormat /dev/sda1
> cryptsetup luksOpen /dev/sda1 crypt_1

We add the encrypted device to the filesystem and remove the other one

> btrfs device add /dev/mapper/crypt_1 /mnt/tmp
> btrfs device remove /dev/sda2 /mnt/tmp

This will again take a long time for a filesystem with a lot of data, as all data have to be moved.

We then convert the other device to LUKS, add it back to the filesystem and rebalance as Raid1:

> cryptsetup luksFormat /dev/sda2
> cryptsetup luksOpen /dev/sda2 crypt_2
> btrfs device add /dev/mapper/crypt_2 /mnt/tmp
> btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/tmp
Done, had to relocate 3 out of 3 chunks

Of course the last command will again take a long time if we have a lot of data. Let's check the result:

> btrfs filesystem show /mnt/tmp
Label: none  uuid: e894df1a-b62f-49cb-bcdc-8e6eb25945a4
        Total devices 2 FS bytes used 448.00KiB
        devid    3 size 9.98GiB used 1.28GiB path /dev/mapper/crypt_1
        devid    4 size 9.98GiB used 1.28GiB path /dev/mapper/crypt_2
> btrfs filesystem df /mnt/tmp
Data, RAID1: total=1.00GiB, used=320.00KiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=256.00MiB, used=112.00KiB
GlobalReserve, single: total=16.00MiB, used=0.00B

Voilá, we have a RAID 1 on two encrypted devices, still containing our data!

> cat /mnt/tmp/hello.txt 
Hello World

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .