From time to time, you will come across a restricted environment that can prevent you from creating good and functioning backups. One scenario could be that you are not allowed to attach external storage to a host and that all data must be encrypted to prevent data leakage.
This case scenario is based on using a Linux workstation that has remote network storage via Samba or Windows shares. All Linux distributions should work similar based on the information below, however, this was conducted using RHEL, so direct usage for Scientific Linux and CentOS should work.
First off, we are going to be performing this all in the terminal, so don’t bother hooking to shares via the File Browser GUI.
Create easy access mount points that we will be using:
sudo mkdir /backup-storage /backup
Make sure these directories don’t exist on your system already. If they do, adjust this and the following procedures accordingly to fit your requirements.
Lets mount our remote storage. In this case, I am using an IP address as VPN software could impact the work group broadcast information of hosts on the network:
sudo mount -t cifs -o username=mrbackup //192.168.1.250/backups /backup-storage
Obviously, change the usual parameters to fit your environment.
Now, this step is only required the first time you set up this process. We need to create a file boundary that our encrypted file system will live within:
sudo dd if=/dev/zero of=/backup-storage/workbackup.luks bs=1024 count=30720000
This will create a 30GB file on the remote storage. I have used an extension of .luks just to make it easy for me to identify what the file is. You can remove the extension if you are trying to hide the identity of what is in the file, however, this would be security by obscurity as it would be easily identifiable by performing file <filename> if others (or root/Administrators) have access to the file. Personally, I would be ensuring that I create this file in a server location that is not shared by others.
Now to find a loop back device that isn’t being used:
sudo losetup /dev/loop0
If it returns “No such device or address” then you are good to use it for the purpose of creating your local loop back file system.
sudo losetup /dev/loop0 /backup-storage/workbackup.luks
Now we have a device that we can use and treat as if it was physically attached storage.
Time to setup the base encryption for our backup file. Linux Unified Key Setup or LUKS is the best solution for this requirement.
sudo cryptsetup luksFormat /dev/loop0
You’ll be asked to enter a pass phrase here, so use a complex one, but easy for you to remember. If you forget your pass phrase, you’ll never* be able to recover your data.
* You can use keys etc, but we are trying to keep this simple. However, without alternative means, you’ll never decrypt the file.
Now we need to map our loop back device (which is actually a file) into the device tree with LUKS to manage communication into and out of the file:
sudo cryptsetup luksOpen /dev/loop0 backup
This will create, technically, a device in the /dev/mapper directory called backup.
We now need to create a file system in our encrypted device so we can perform standard file system operations, just as you would with any other file system on a Linux host:
sudo mkfs.xfs /dev/mapper/backup
I have used XFS in this case as it is my preferred file system that has rock solid stability and proven track record.
Mount our newly created filesystem that is nested inside a LUKS encrypted file:
sudo mount /dev/mapper/backup /backup
Lets set the permissions on the root of this filesystem so you can write out to it as an unprivileged user:
sudo chown mrbackup /backup && chmod 700 /backup
This will ensure that it is my own filesystem and that no other users that maybe logged into my workstation has access to the files that are located in my backup.
So my backups are quick and only need to copy what has changed, lets use RSYNC. We’ll also clean up our backup, removing files that are no longer needed (as we have deleted them from our local copy anyway):
rsync -av –delete /home/mrbackup/. /backup/
Don’t use * or the -z switch. Using * will prevent –delete from working as intended. Using the -z switch is pointless as rsync is only occurring locally and would cause more CPU activity than actually required (it will be compressing and un-compressing without any performance gains – it will actually be slower).
Since we have now finished our backup, there is no longer a need (and actually good practice) to have the backup mounted to the host. Un-mount the backup file system:
sudo umount /backup
Close the encrypted file system and then un-mount the loop back file system. This will ensure that you don’t corrupt the encrypted file:
sudo cryptsetup luksClose backup
sudo losetup -d /dev/loop0
And finally un-mount your Windows Share:
sudo umount /backup-storage
I need to add a note of caution. Managing an encrypted file system over a network is fraught with all sorts of complexities, the main being that the encrypted file becoming corrupt due to network errors or outages. In my experience, my backup network is extremely stable and never has caused me issues. However, this might not be the case for you, so I am just warning you now.
As with all backups, they aren’t really backups unless you test the files that reside in your backups. Test the integrity of your files often as you don’t want to find out that the backup is ‘borked’ when you need it most.