Here’s my new backup strategy. It uses luks, cryptsetup and rsync.

Note: This post is very Linux command-line heavy.

This is a continuing series about operating a home server. Part 1 (HDD) of the saga is here. Part 2 (ZFS) can be found here. Part 3 (GPU) is found here. Part 4 (KVM) is here. Part 5 (L2ARC Cache) is here.

Remember, 3-2-1: 3 copies, on 2 different physical mediums, with 1 offsite copy. Rsync to the rescue!

How else would I save my collection of precious cat pictures from certain disaster?

Currently, my offsite backup is an 8 TB hard drive and some mirrored LTO5 tapes. This backup includes everything on BAXIAL’s (my main linux server) /media/BAXIAL’s ZFS pooled drives (with the exceptions of /Movies and /TV Shows) because of space constraints. I do have multiple copies of these folders elsewhere.

I’ll be updating this backup every 90 days. I will be sneakernetting it over to a friends house.

Making the Backups

I’m using CMD Generator (a nice bash command generator) to create the rsync command I’ll be using for backups. Right now, this will happen manually. In the future, it should happen automatically.

Here is the command for the initial copy (with a dry run):

rsync -vrlpt --exclude "TV Shows/" --exclude Movies/ --progress --dry-run /media/BAXIAL /media/brendan/BPSOFFSITE1

Here’s the command for the initial copy (without a dry run):

rsync -vrlpt --exclude "TV Shows/" --exclude Movies/ --progress /media/BAXIAL /media/brendan/BPSOFFSITE1

To update the files listed, and to delete files that no longer exist on the source /media/BAXIAL pool, I’ll use this command:

rsync -vrlptui --delete --exclude "TV Shows/" --exclude Movies/ --progress /media/BAXIAL /media/brendan/BPSOFFSITE1

Remember, rsync prefers relative paths when you are already in the directory you want to backup. If you are at a bash prompt in your home directory, use the absolute path in the command.

A .txt list of files

I also wanted a list of media files in the /media/BAXIAL/Movies and /media/BAXIAL/TV Shows folders should I ever want a record. In a SHTF scenario, for example, it would be nice to have some ability to know exactly what media I had in those folders.

The commands to create those text files are listed below. The first command (sans -R) creates a list of first-level folders inside the listed directory. Then, the -R option creates recursive listings for each folder and sub-folder inside the listed directory.

ls /media/BAXIAL/Movies > list_moviefolderfiles.txt
ls -R /media/BAXIAL/Movies > list_moviefolderfiles.txt
ls /media/BAXIAL/TV\ Shows/ > list_tvshowsfolderfiles.txt
ls -R /media/BAXIAL/TV\ Shows/ > list_tvshowsfolderfiles.txt

Eventually, it would be useful to have these bash scripted to run before starting a new file sync.

Why LUKS Encryption?

Encryption on the data at rest would be good. It would stop someone from plugging in the drive and seeing identifying documents and personal photographs. With a strong passphrase, it should be virtually impossible. At least until quantum computing can break encryption in seconds with a future variation on rainbow tables.

I used a few online guides to figure out how to setup and use cryptsetup utility for encrypting the disk. Then, I can mount the disk and use rsync as described above and transfer data.

Future options include using a detached LUKS header or using a keyfile in addition to the passphrase.

Cryptsetup

The cryptsetup man pages have the programs functions explained.

1. To begin using cryptsetup, I needed to install it on my system. On Ubuntu this means using apt.

sudo apt install cryptsetup-bin

Next, I plugged the external HDD into a USB 3.0 port on my computer and ran lsblk to list all block devices connected to my computer and find out the name of my external drive. My drive is sde. Using fdisk -l the device is located at /dev/sde. 1.

I started the cryptsetup process.

sudo cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 /dev/sde

You’ll need to change dev/sdX to the name of your connected drive.

1. We open the new LUKS partition. It will prompt you to enter a passphrase.

sudo cryptsetup luksOpen /dev/sde BPSOFFSITE1

1. We check the disks status, to ensure everything is active.

sudo cryptsetup -v status BPSOFFSITE1

1. We create a filesystem on the device.

sudo mkfs -t ext4 -V /dev/mapper/BPSOFFSITE1

1. We create a new mount point, so that the drive can mount and be seen by the file browser.

sudo mkdir /media/BPSOFFSITE1

1. We mount the device on to the system.

sudo mount /dev/mapper/BPSOFFSITE1 /media/BPSOFFSITE1

For now the drive is unlocked and able to read and write data.

Following stephandroid.com’s guide I mounted and unmounted the drive several times. I also did the same in my file browser as I will be using the GUI under my regular user account when I do backups.

When using my file browser to mount and unmount the drive, it mounts the drive to /media/brendan/[UUID]. Meaning that the drive was no longer accessible at /media/BPSOFFITE1

The drive was no longer accessible because I had mounted it using the file manager in the GUI under my regular user account.

The drive was mounted, by default, to the system at /media/brendan/[UUID]. The UUID is a long string of alphanumeric characters making it harder to reference or remember.

1. I changed its label to make it easier to reference and remember.

sudo cryptsetup config /dev/sde --label BPSOFFSITE1

1. I went into the Gnome Disks app GUI and changed the label there too. This will make it easier to remember when doing backups. In my specific case, the drive will be located at /media/brendan/BPSOFFSITE1.

Logically, the drive was still located at /dev/sde meaning that I could reference that to see LUKS information.

1. To check the disk for information about its encryption we can use the following,

sudo cryptsetup luksDump /dev/sdX

1. I created a backup of the LUKS header. If you do this, save the keyfile to another secure device. The reason we make a backup is to allow a restore of the device header if it is ever corrupted on the original drive.

sudo cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /home/brendan/[nameoffile]

Once the header file was backed-up, I needed to change the ownership of the file from root to my user.

sudo chown [username] header_file.bin

1. I added a second passphrase to key slot 1 as a backup. It will ask for the original passphrase, then you input the new passphrase twice.

sudo cryptsetup luksAddKey --key-slot 1 /dev/sdX

1. We can verify that it added the second passphrase by running luksDump again, as above.

Finally, I was ready for my first backup using rsync!

Post Mortem

It took about 18 hours, but I backed up over 6 TB of data. The drives made a lot of noise reading all the data. The updates using rsync are much faster with the -u flag set.

It would be useful to have email reports sent to me when rsync is successful...