I want to be able to remote-control the launch of a restic backup via SSH from a “controlled” client (“C” in the diagram below) while being able to access the actual backup directly from “C”. The remote control is used so as to not have to keep the password of restic’s backend on the machines in the center.

diagram of Restic via SSH

In this instance, the backup server is the rest-server as it’s the fastest restic backend.

The client exports the password for the backend store as an environment variable. Our SSH server already accepts LC_ environment variables so we use one of those:

# sshd: Allow client to pass locale environment variables
AcceptEnv LANG LC_*

On the machines which will be backed up (in the center of the diagram), I have an authorized_keys entry for a dedicated user:

command="/home/resticuser/runb.sh",no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAAC....

The small shell script does a bit of logging and sets the correct environment variable for restic to authenticate to its destination REST server before actually running the backup:

#!/bin/sh

echo "** kick restic on $(hostname)"

export RESTIC_REPOSITORY="rest:https://ruser:password@store.example.net:8000/bak"
export RESTIC_PASSWORD="${LC_RESTICPW}"

restic --cacert ca.pem backup /data

This small script can optionally check $SSH_ORIGINAL_COMMAND to determine which portion of the system respectively which database it should back up.

On the controlling side (the “C” at the top of the diagram), I kick the backup this via

#!/bin/sh

export LC_RESTICPW=<supersecretpasswordfromsomewhere>
ssh -o IdentityFile=keyfile \
    -o IdentitiesOnly=true \
    -o SendEnv=LC_RESTICPW \
    -l resticuser \
    $middlebox

I’ve also prototyped a very similar setup with BorgBackup because we just might decide to use that in this particular case as pruning is quite a bit faster, and we’re interested in the different compression methods it has to offer.

backup and restic :: 12 Apr 2019 :: e-mail