«

»

How to securely backup LUKS-encrypted partitions, incrementally.

These days, security is at the forefront of many computer users’ minds. Running your primary machine with encryption is important to ensure privacy and security. Generally, the most common form of partition level encryption for Linux machines is the LUKS encryption specification which is directly supported by the Linux kernel.

Most file level backup applications (like rsync) require that the partition already be decrypted so it can backup the files. This is inherently insecure in that the partition must remain open/decrypted for the backup to take place. In addition, the backed up files at the destination will be unencrypted.

The solution is to backup the encrypted partition in its raw, encrypted form, directly at the block level. Should a restore ever be necessary, you’d restore the entire partition data back to an empty partition whereupon you can then mount the LUKS partition and decrypt the data.

Enter: Bdsync. It is not yet available in the Debian or Ubuntu/Mint repositories, but it can be directly downloaded. I hope in the near future this application will be added to the repositories for easier installation.

From the Bdsync manpage:

Bdsync can be used to synchronize block devices over a network. It generates a “binary patchfile” in an efficient way by comparing checksums of blocks of the local block device LOCDEV and the remote block device REMDEV.

This binary patchfile can be sent to the remote machine and applied to its block device REMDEV, after which the local blockdev LOCDEV and the remote block device REMDEV are synchronized.

bdsync was built to do the only thing rsync isn’t able to do: synchronize block devices.

Essentially Bdsync generates an MD5 hash checksums for each data block on the partition. It compares them between the source and destination. If there’s any differences for any block, just that block is copied to the destination. It works very much like rsync, just at the block level.

When used for the first time, Bdsync will have to copy every data block to the destination (via scp) which will take a while since it is essentially going to copy the entire partition.

The command to run a Bdsync on your partition will look something like this:

# bdsync "ssh root@remote_host bdsync --server" /dev/sdx1 /dev/copysdx1 | gzip > /some_local_path/sdx1-bdsync.gz

This will ssh to the remote host (server) and run Bdsync on the local partition and copy pipe it through gzip for compression to a path on the remote host side. I recommend trying this backup and restore process first on a test virtual machine as the source-data and then copy it out to the server hosting the virtual machine. Then try to do a restore to the virtual machine. If all goes well, you’ll feel comfortable with the process to do it for real.

For a restore, you’d simply run bdsync in reverse, with the “source” being the remote host copy of the partition and the destination being what you want to restore to.

In addition Bdsync works on any block device such as LVM volumes and RAID volumes. The destination for the copies also does not have to be network-based. They can easily copy to local, external USB drives.

This blog post may seem a bit sparse on the details and I know I’m just covering the broad strokes, but doing a block level incremental backup is an advanced topic and not meant for the uninitiated.