0

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?

0

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

...

Devices:
   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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.