Backup parts encrypted with luks on Linux

Time:2021-7-29

For security reasons, some of us encrypt hard disk drives at home or on VPS through Linux unified key configuration (luks), and the capacity of these drives will soon grow to tens or hundreds of GB. Therefore, although we enjoy the security brought by luks devices, it’s time to start considering a possible remote backup scheme. For secure off-site backup, we will need something that can operate at the block level on luks encrypted devices. Therefore, in the end, we found that we need to transfer the entire luks device that we want to backup every time (for example, 200GB). Obviously, this is not feasible. How should we deal with this problem?
One solution: bdsync

At this time, an excellent open source tool came to save us. It was called bdsync (thanks to Rolf fokkens). As the name suggests, bdsync can synchronize “block devices” over the network. For fast synchronization, bdsync will generate and compare the MD5 checksum of blocks of local / remote block devices, and only synchronize the difference part. Rsync can do it at the file system level, and bdsync can do it at the block device level. Naturally, it works well for luks encrypted devices. Quite clever!

With bdsync, the first backup copies the entire luks block device to the remote host, which takes a lot of time to complete. However, after the initial backup, if we create some files on the luks device, the second backup will be completed quickly, because we only need to copy the modified blocks. The classic incremental backup is working!
Installing bdsync to Linux

Bdsync is not included in the standard repository for Linux distributions, so you need to build it from source code. Use the following version specific instructions to install bdsync and its man pages into your system.
Debian, Ubuntu or Linux MINT

   

Copy code

The code is as follows:

$ sudo apt-get install git gcc libssl-dev
$ git clone https://github.com/TargetHolding/bdsync.git
$ cd bdsync
$ make
$ sudo cp bdsync /usr/local/sbin
$ sudo mkdir -p /usr/local/man/man1
$ sudo sh -c ‘gzip -c bdsync.1 > /usr/local/man/man1/bdsync.1.gz’

Fedora or CentOS / RHEL

   

Copy code

The code is as follows:

$ sudo yum install git gcc openssl-devel
$ git clone https://github.com/TargetHolding/bdsync.git
$ cd bdsync
$ make
$ sudo cp bdsync /usr/local/sbin
$ sudo mkdir -p /usr/local/man/man1
$ sudo sh -c ‘gzip -c bdsync.1 > /usr/local/man/man1/bdsync.1.gz’

Implement off-site incremental backup for luks encrypted devices

I assume that you have prepared a block device encrypted by luks as the backup source (for example, / dev / locdev). At the same time, I assume that you also have a remote host as the backup point of the source device (e.g. / dev / remdev).

You need to have root account access on both systems and set password free SSH access from local access to remote access. Finally, you need to install bdsync on both hosts.

To initialize a remote backup process on the local host, we need to execute the following command as root:

   

Copy code

The code is as follows:

# bdsync “ssh [email protected]_host bdsync –server” /dev/LOCDEV /dev/REMDEV | gzip > /some_local_path/DEV.bdsync.gz

Some explanation is needed here. The bdsync client will open an SSH connection to the remote host as root and execute the bdsync client with the — server option. To be clear, / dev / locdev is the source luks block device on our local host, and / dev / remdev is the target block device on the remote host. They can be / dev / SDA (as an entire disk) or / dev / sda2 (as a single partition). The output of the local bdsync client is then piped to gzip to create dev.bdsync.gz (the so-called binary patch file) in the local host.

The first time you run the above command, it will take a long time, depending on your Internet / LAN speed and the size of / dev / locdev. Remember, you must have two block devices of the same size (/ dev / locdev and / dev / remdev).

The next step is to copy the patch file from the local host to the remote host. One way is to use SCP:

   

Copy code

The code is as follows:

# scp /some_local_path/DEV.bdsync.gz [email protected]_host:/remote_path

The final step is to execute the following commands on the remote host, which will apply the patch file to / dev / remdev:

   

Copy code

The code is as follows:

# gzip -d < /remote_path/DEV.bdsync.gz | bdsync –patch=/dev/DSTDEV

I recommend using small partitions (without any important data) to do these tests before deploying bdsync with real data. After you understand how the whole data is backed up, you can fully understand how it works.
Epilogue

In summary, we demonstrated how to use bdsync to implement incremental backup for luks devices. Like Rsync, only a small part of data is backed up each time, instead of the entire luks device, which needs to be pushed to the off-site backup point, which will save bandwidth and backup time. The rest is to ensure the security of all data transmission through SSH or SCP. In fact, the device itself is encrypted by luks. You can also improve this configuration by using a dedicated user who can run bdsync instead of root. We can also use bdsync for any block device, such as LVM volume or RAID disk, or easily set bdsync to back up the local disk to the USB drive. As you can see, it has infinite possibilities!