Page tree
Skip to end of metadata
Go to start of metadata

In October 2020 the CoreTeam has made a new storage system available at that can be accessed through SFTP.

Using a combination of SSHFS and LUKS this can be used to store backups encrypted, while still being able to send incremental updates using rsync.

The idea is as follows:

  • Create a single LUKS container in a file stored on the backup storage.
  • Mount the backup storage on your local VPS via SSHFS.
  • Use Linux cryptsetup to access the encrypted contained on your VPS.
  • Mount a filesystem created inside it locally and rsync your backup data to it.

Preliminary setup

On a Debian-like system, install the following packages:

Installing dependencies
apt-get install cryptsetup sshfs

Make sure that you have SSH access to (the local LAN variant to reduce load on the WAN interface). Add something like below to /root/.ssh/config:

SSH configuration
Host soleus-backup
    User <your-soleus-username>
    IdentityFile <path-to-ssh-key-with-console-access>

Note that it is probably convenient to have an SSH key without passphrase to automate things.

Creating the LUKS container

All paths below are matching the backup script and user root is assumed, adapt to your needs.

Mount your backup space locally:

Mounting the remote storage
mkdir /mnt/backup-soleus
sshfs soleus-backup: /mnt/backup-soleus

Create a password for the LUKS container and store it if you want to automate things. Otherwise, you have to enter it manually whenever opening the LUKS container.

Creating a LUKS password
makepasswd --chars 20 > /root/.backup-password
chmod go= /root/.backup-password
Make sure to also save this somewhere off your VPS!

Now create the LUKS container file, with zeros or random data to be more secure:

Create the LUKS file
dd if=/dev/urandom bs=1M count=20480 | pv >> /mnt/backup-soleus/backup-crypt.img

The pv is there just to measure progress. Note that you can always increase the container size later, but I don't think you can shrink it. Unfortunately this takes some time, and a quick fallocate does not seem to work over SSHFS.

If you are using /dev/zero as source for the 'filler' data, you can use the -C (compression) option with sshfs to drastically (10 - 15x) speed up this process. Of course this will mean a containers with zeroes, not random data. If you are using /dev/urandom and once you are using the encrypted container, this will not make any difference as random and encrypted data are non-compressible.

Finally initialize the file:

Format the LUKS container
cryptsetup luksFormat -d /root/.backup-password /mnt/backup-soleus/backup-crypt.img
Leave out the -d /root/.backup-password to enter the password manually.

Now open the LUKS volume (here as Device Mapper device backup) and create your favourite filesystem inside it:

Open the LUKS container
cryptsetup -d /root/.backup-password open /mnt/backup-soleus/backup-crypt.img backup --type luks
mkfs.ext4 -L backup /dev/mapper/backup

Test mount it, create an appropriate directory in it to store your backups:

Mount the LUKS container
mkdir /mnt/backup-crypt
mount /dev/mapper/backup /mnt/backup-crypt
mkdir /mnt/backup-crypt/backup
The script below assumes an fstab entry for this filesystem exists.

Finally, close everything:

Close the LUKS container
umount /mnt/backup-crypt
cryptsetup close backup
fusermount -u /mnt/backup-soleus

Resizing the LUKS container

If you find that the LUKS container has too little space to contain your backups, it can fairly easily be resized. First mount the backup space, then extend the LUKS file, run the resize command for the LUKS container, and then for the FS inside it:

Resizing the LUKS container
sshfs soleus-backup: /mnt/backup-soleus
dd if=/dev/urandom bs=1M count=10240 | pv >> /mnt/backup-soleus/backup-crypt.img
cryptsetup -d /root/.backup-password open /mnt/backup-soleus/backup-crypt.img backup --type luks
resize2fs /dev/mapper/backup

This increases the backup container by 10GB.

Running backups

After this setup, the shell script below should allow you to make backups. Of course the precise way and what to backup can be adapted in the backup_run() function. You can for example create LVM snapshots of your logical volumes and backup these to guarantee a consistent state, or use hardlinks to keep full backups from multiple dates with little overhead, à la rsnapshot. I, Jaap Eldering, author of this script, am doing both these things; feel free to contact me for more details.

Backup script
#!/bin/sh -e
# A simple script to make encrypted backups to a remote server with SSH
# (non-shell) access only. No data leaves the local system
# unencrypted, and only differences are transferred. The backup can be
# mounted locally as a normal filesystem.
# Copyright 2015--2017 Jaap Eldering <>
# This program is licensed under the MIT license, see:

# Mountpoints for SSHFS of and FS contained in LUKS image:

# LUKS image path in SSHFS mounted partition:

# Device Mapper device name for LUKS image:

# File containing password for LUKS image, leave unset to get prompted:

# Sleep command executed between mount command, just to be sure that
# each action is fully completed before the next step.
SLEEP="sleep 0.2"

	sshfs -o reconnect,sshfs_sync soleus-backup: $SSHFS_MNT
	cryptsetup ${PWFILE:+-d $PWFILE} open $SSHFS_MNT/$IMAGE $DEVNAME --type luks
	[ "$1" = nofsmount ] && return
	mount $CRYPT_MNT

	findmnt $CRYPT_MNT >/dev/null && umount $CRYPT_MNT
	cryptsetup status >/dev/null $DEVNAME && cryptsetup close $DEVNAME
	findmnt $SSHFS_MNT >/dev/null && fusermount -u $SSHFS_MNT

	rsync -a --delete \
		  --exclude=/dev --exclude=/mnt --exclude=/proc \
		  --exclude=/run --exclude=/sys --exclude=/tmp \
		  / $CRYPT_MNT/backup/

case "$1" in
	mount)	do_mount ;;
	umount)	do_umount ;;
		do_mount nofsmount
		fsck -f /dev/mapper/$DEVNAME
		echo "Error: unknown command '$1'."
		exit 1

exit 0


  1. I have Debian 10/Buster on my VPS and got this when installing cryptsetup:

    update-initramfs: Generating /boot/initrd.img-4.19.0-13-amd64

    cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries

    nor crypto modules. If that's on purpose, you may want to uninstall the

    'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs

    integration and avoid this warning.

    1. I've seen that too and it's a harmless warning as you're not booting from this LUKS file system. I guess you could follow the suggestion to remove that cryptsetup-initramfs package.