Migrate all the things!!
As i stated in my previous post my primary harddrive is failing on me. To be proactive i am replacing it before it fully dies.
So this will be a somewhat technical post where I will outline the steps I took to migrate to my new HDD. Some of these steps will be specific to my setup but most could be applied to other situations. Hope you find some of this useful or at least informational.
First some details on the setup. I use BTRFS as my filesystem on all my drives. BTRFS provides a subvolume functionality. Subvolumes are similar to partitions in which they can be mounted/accessed independently from the main/root of the filesystem. So my old drive was setup with the following subvolumes:
| Subvolume | Description |
|---|---|
| @Home | This contains my Home partition |
| @Storage | This contains my primary storage (Hold Downloads,Wallpapers and other general data) |
| @HomestBU | This was used to make backups(More will be explained on how to handle backups with BTRFS subvolumes/snapshots) |
This same layout will be replicated on the new drive later.
To avoid any data loss I had moved my @Home subvolume to my raid5 array(Called Storage2) which typically holds my media files and my @Storage subvolume to my external storage device(called Storage3) that normally holds my backups. Now the task will be to move those subvolumes to the new harddrive. So lets get on with it.
This is the drive I am migrating stuff to
Lets begin the migration.
Since I have all my storage encrypted the first step is to setup the encryption container. This is done by issuing the following cammand:
cryptsetup -v --type luks --cipher anubis-xts-plain64 --keysize 640 --hash whirlpool --iter-time 5000 --use-random -d /etc/homest luksFormat
Lets breakdown that command a bit shall we
| Option | Desctiption |
|---|---|
| -v | This simply makes the cryptsetup command output mor detailed information about what it does |
| --type luks | This instructs cryptsetup that we are working in luks mode instead of plain mode (See here for an explanation of the differences between plain and luks mode.) |
| --cipher anubis-xts-plain64 | This is defining the cipher to be used for the encryption operation. I always use a cipher that is not as mainstream. In this case i am using the anubis cipher. I like this cipher for a few reasons. One of them being that it is named after an egyptian god and the creator has stated that anyone who breaks it will be cursed. |
| --keysize 640 | This defines the size(in bits) of the key used for encryption. The bigger the key the stronger the encryption. Anubix has a maximum key size of 320 but since the xtx cipher mode splits the key in 2 we specify 640 here. |
| --hash whirlpool | This defines what hash function(default sha256) will be used the hash the passphrase. |
| --iter-time 5000 | This defines how long(in miliseconds) cryptsetup will spend processing the keyphrase. Default is 1 second I make it go for 5. |
| --use-random | This define the source used for the generation of random numbers used by the format process. Choices are urandom or random. I always use random as it produces a more random result |
| -d /etc/homest | This defines a keyfile to use instead of prompting for a passphrase. That key file is a giant string of random characters |
| luksFormat | This just says to format the device that follows |
| /dev/sdxY | The device to format |
Now that the encrypted container is ready we can open it to use it:
cryptsetup open -d /etc/homest /dev/sdxY homest
Now we can format the container with a filesystem:
mkfs.btrfs /dev/mapper/homest
And mount it:
fstab entry
/dev/mapper/homest /mnt/btrfsroot btrfs compress=zlib,space_cache=v2 0 0
mount /mnt/btrfsroot
Starting with my @Storage subvolume we will now move it to the new drive
First we create a read-only snapshot of the subvolume:
btrfs subvol snap -r \@Storage/ \@Storage.migrate
A snapshot is like a picture of the data currently in that subvolume.
Now we send it over to the new drive:
btrfs send -vvv \@Storage.migrate/ | btrfs receive -vvv /mnt/btrfsroot/
Once this is complete we update the fstab entry to mount the subvolume from it's new location:
/dev/mapper/homest /media/Storage btrfs compress=zlib,space_cache=v2,subvol=@Storage 0 0
Notice how this entry is similar to the previouse with the differences being the mountpoint(/media/Storage) and that we specify the subvolume to mount.
Now we do the same thing with the @Home subvolume.
First we create a read-only snapshot of the subvolume:
btrfs subvol snap -r \@Home/ \@Home.migrate
Now we send it over to the new drive:
btrfs send -vvv \@Home.migrate/ | btrfs receive -vvv /mnt/btrfsroot/
Once this is complete we update the fstab entry to mount the subvolume from it's new location:
/dev/mapper/homest /Home btrfs compress=zlib,space_cache=v2,subvol=@Home 0 0
Now the subvolumes on the receive side(now in /mnt/btrfsroot) are still in read-only mode which wont work. To resolve that we simply take a read-write snapshot of the subvolume:
btrfs subvol snap \@Home.migrate \@Home
btrfs subvol snap \@Storage.migrate \@Storage
And That is it. Migration complete. All that is left to do is reboot to start using the new drive. Hope you maybe found this post informational.
Have a great day.
G
#Tech #Migration #Linux #BTRFS
Until next time. Stay safe!