MTA-Backups / Duplicty

There is a regular backup ran from systemd; /etc/duplicity. It starts with a full dump of all MySQL tables. It is encrypted against a public key; the private key of which is held by the Trustees of the foundation.
Crontab kicks off a script;
# weekly full, incrementals during the week. # 3 3 * * 0 root test -x /etc/duplicity/run.sh && /etc/duplicity/run.sh full 3 3 * * 1-6 root test -x /etc/duplicity/run.sh && /etc/duplicity/run.sh incremental
# Half year retention for full; 3 months for the incrementals # 1 1 * * 1 root test -x /etc/duplicity/run.sh && /etc/duplicity/run.sh remove-all-but-n-full 32 1 2 * * 1 root test -x /etc/duplicity/run.sh && /etc/duplicity/run.sh remove-all-inc-of-but-n-full 12
The script: run.sh:
#!/bin/sh set -e umask 077 DIR=/etc/duplicity W=incremental if [ $# != 0 ]; then W=$1 shift fi T= if [ $W = full -o $W = incremental ];then T=/ mysqldump --all-databases --single-transaction --quick --lock-tables=false | gzip -9 > /var/lib/mysql-files/mysql-dump.gz fi # Verbose level 2 is errors and warnings; this way we skip # notices and quell all output if the backup is a success. # PASSPHRASE="YYYPASSWORD" \ LANG=en_US.UTF8 LC_CTYPE=C HOME=$DIR GNUPGHOME=$DIR \ PYTHONWARNINGS="ignore::DeprecationWarning" \ python3 -W ignore::DeprecationWarning /usr/bin/duplicity $W $* \ \ -v 2 \ --hidden-encrypt-key XXXXX \ --hidden-encrypt-key YYYYY \ --sign-key YYYYY \ --ssh-options="-i $DIR/backup.sftp -oUserKnownHostsFile=$DIR/knownhosts" \ --no-print-statistics \ \ --include /etc \ --include /usr/share/mediawiki \ --include /usr/share/wordpress \ --include /usr/local/makerspaceleiden-crm \ --exclude /var/lib/lxcfs \ --include /var/lib \ --include /var/www \ --include /var/log \ --exclude /dev \ --exclude /sys \ --exclude /run \ --exclude /tmp \ --exclude /snap \ --exclude /var/tmp \ --exclude /proc \ --exclude /swapfile \ --exclude /etc/duplicity/.cache \ \ $T \ sftp://msl@crimson.webweaving.org/backups 2>&1 |tee /var/log/last-duplcity-backup.new | grep -v DeprecationWarning | grep -v algorithm=hashes.SHA1 mv /var/log/last-duplcity-backup.new /var/log/duplicity.log mv /var/log/duplicity.log.gz /var/log/duplicity.prevlog.gz || true gzip /var/log/duplicity.log || true exit $?
Importing a new public key is done as follows
cd /etc/duplicity cp XXXX/public-key-12345.gpg . gpg --homedir . --import public-key-12345.gpg . gpg --homedir . --edit-key XXXXXX trust 5 save
And test by running it manually
sudo /etc/duplicity/run.sh incremental
== Ransomware/targeted risk ==
This approach is not overly resistant against a targeted delete - as the sftp user can delete/modify files (as the retention is currently done from the 'source'). This is, to some extend, mitigated by snapshots -- but not sufficiently at this time.