Linux: Borgbackup mit AmazonDrive, OneDrive oder doch SSH?

Ich bin schon vor einiger Zeit auf das Backuptool borgbackup gestoßen. Da meine Backups immer sauber liefen war bis jetzt kein Bedarf da, das Backupverfahren zu ändern. Durch das langsam immer weiter wachsende Datenvolumen und auch dem somit wachsenden Backups stand ich vor der Wahl mehr Geld auszugeben um den Backupspeicher zu erweitern oder ein effizienteres Backup durchzuführen.

Beweggrund

Also einen Blick auf borgbackup geworfen. Das basiert auf Python (*grmpf*) und legt verschlüsselte Backups lokal, per SSH oder SSHFS an. Das erste Backup ist immer ein Vollbackup. Die darauf folgenden sind von da ab nur noch inkrementelle Backups basierend auf dem letzten. Der Vorteil liegt klar auf der Hand. Kleinere und damit Bandbreiten schonenden und schnellere Backups. Für mich muss sich sowas aber auch immer in der Praxis eine Gewisse Zeit bewähren, bevor ich andere Lösungen als bereits etablierte in Betracht ziehe.

Bordbackup Dokumentation

Das Tool ist in der Tat wirklich gut dokumentiert. Hinzu kommt auch, dass es in Debian 8 bereits in einer recht aktuelle Version (1.0.10-2) enthalten ist.

Sicherungsvarianten

Für gehostete Systeme bietet sich immer eine Sicherung auf ein nahes und gut angebundenes Backup System an. Ja, Datenschutz… aber es ist dennoch einen Blick wert. Die Alternative wäre die Sicherung per SSH auf ein System zuhause. Dies ergibt somit drei Sicherungsoptionen:

• OneDrive
• Amazon Drive
• SSH

OneDrive

OneDrive ist aus dem Grund interessant, als das man als Office365 Kunde 1 TB Speicher kostenlos erhält. Leider ist OneDrive nicht mit Standard Protokollen wie FTP, SSH erreichbar. Es gibt darüber hinaus auch kein aktuelles Tool um ggf. über die API OneDrive zu mounten. Die Option scheidet damit schon mal aus.

Amazon Drive

Amazon bietet für 70 € im Jahr unbegrenzten Speicherplatz. Soweit erstmal gut. Leider sind auch hier Standard Protokolle nicht nutzbar. Es gib aber einen Client namens acd_cli, der es erlaubt AmazonDrive zu mounten. Ein Minuspunkt dabei ist ganz klar, dass es ein proprietäres Tools ist und die Langzeitunterstützung somit ungewiss. Ändert Amazon die API und der Client wird nicht angepasst, kommt man nicht mehr ohne weiteres an die Backups und muss erst eine Zwischenlösung (z.B. lokal herunterladen) nutzen. Dies ist im Problemfall ein zusätzlicher Zeitfaktor, den keiner gebrauchen kann.

Dennoch hat es mich gereizt, es einmal auszuprobieren. Zur Absicherung der Daten mach die Verwendung von EncFS Sinn. Technisch gesehen sind für jede Sicherung also folgende Schritte notwendig.

1. Amazon Drive mounten (/mnt/acd)
2. EncFS Mounten (/mnt/encfs)
3. Borgbackup ausführen
4. EncFS unmounten
5. Amazon Drive unmounten

apt-get install python3-llfuse fuse

# Mount ACD
acdcli mount /mnt/acd

# Mount EncFS
encfs /mnt/acd/<hostname>/ /mnt/EncFS/
cat .encfs_secret | ENCFS6_CONFIG='.encfs6.xml' encfs -S -o allow_other /mnt/acd/<hostname>/ /mnt/encfs/

# Borgbackup
 borg create  -v --compression lzma,4 --stats --progress /mnt/encfs::2017-04-01-configs $(cat ~/list_of_config_files)

# umount EncFS
fusermount -z -u /mnt/EncFS

# Umount ACDacd_cli umount

Soweit so gut oder auch schlecht. Denn der Sicherungsprozess ist unnötig kompliziert und damit Fehleranfällig was sich in den Tests leider auch gezeigt hat. Die Sicherung läuft nicht immer sauber durch. Teilweise bleibt der Lock auf der Sicherung bestehen und muss vor dem nächsten Durchlauf erst aufwändig entfernt werden. Aktuell kann ich daher keinem dazu Raten, diesen Weg zu nutzen.

SSH

Für eine Sicherung per SSH gibt es zwei Möglichkeiten. Einmal die Nutzung von SSHFS, also dem mounten eines entfernen Verzeichnisses über SSH oder die Installation von Borgbackup auf beiden Seiten. Ich habe beides ausprobiert.

SSHFS

Die Einrichtung ist simpel. Man legt auf dem entfernten System einen neuen Benutzer an, weißt diesem einen SSH Schlüssel zu und legt das Verzeichnis zur Sicherung an. Erfolgt die Sicherung dabei auf einen externen Datenträger müssen die Rechte auf den Mount-Punkt so gesetzt werden, dass der Nutzer darauf schreiben darf.

mkdir /mnt/borgbackup
chown borgbackup:root /mnt/borgbackup

Aus Sicherheitsgründen sollte man die Rechte des SSH Nutzers soweit einschränken, dass diese nur auf das Backupverzeichnis zugreifen darf. Irgendwo in der Borgdokumentation bin ich schließlich auf einen Hinweis gestoßen, dass die Beste Geschwindigkeit nur bei der direkten Nutzung einer SSH Verbindung zu erreichen ist. Ein Test hat dies bestätigt. Dazu habe ich ein Backup von mehreren kleinen Datei mit einer Gesamtgröße von 61 MB durchgeführt.

SSH

Für eine reine SSH Nutzung muss auf beiden Seiten (Server und Backupsystem) borgbackup installiert werden. Es empfiehlt sich wieder einen Benutzer sowie einen SSH Schlüssel für diesen zu hinterlegen. Darüber hinaus sollte auf dem Backupserver in der authorized_keys Datei mit angegeben werden, dass dieser Benutzer als Befehl nur borg ausführen darf. Dies steht auch in der Dokumentation gut beschrieben.

command="borg serve --restrict-to-path /path/to/repo",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc ssh-rsa AAAAB3[...]

Was mich wiederum ein paar Minuten recherchieren gekostet hat: wie gebe ich borgbackup den zu nutzenden SSH Schlüssel mit?

Auch dies steht in der Dokumentation, insofern man es findet.

export BORG_RSH='ssh -i borgbackup.key'

Stand heute ist die reine SSH Nutzung meine Favorisierte Lösung. Das ganze sieht dann als Script wie folgt aus.

#!/bin/bash

# export BORG_PASSPHRASE='totalgeheimeskennwort'

ssh_remote_host=backupserver.meinedomain.tld
ssh_remote_folder=/mnt/borgbackup/
ssh_remote_user=borgbackup
ssh_remote_authfile=/home/borgbackup/.ssh/borgbackup.key

#nice="ionice -c3 nice -n 20"

function tempfile() {
  tempprefix=$(basename "$0")
  mktemp /tmp/${tempprefix}.XXXXXX
}

bb_prep() {
  echo "> Settings variables"
  export BORG_PASSPHRASE='totalgeheimeskennwort'
  export BORG_RSH='ssh -i ${ssh_remote_authfile}'

  echo "> Checking repository status"
  borg init ${ssh_remote_user}@${ssh_remote_host}:${ssh_remote_folder}$(hostname)
}

bb_run() {
  temp=$(tempfile)

  echo "> Runing backup of ${1}."
  timestamp=$(date +%Y-%m-%d-%H-%M)

  ${nice} borg create --ignore-inode --compression lzma,4 --stats --progress ${ssh_remote_user}@${ssh_remote_host}:${ssh_remote_folder}$(hostname)::${timestamp}-${2} $(cat ${1})
  ${nice} borg info ${ssh_remote_user}@${ssh_remote_host}:${ssh_remote_folder}/$(hostname)::${timestamp}-${2} | grep -v "Command line" > ${temp}
  echo ${nice} borg info ${ssh_remote_user}@${ssh_remote_host}:${ssh_remote_folder}/$(hostname)::${timestamp}-${2}
  mail -s "$(hostname) backup - [${timestamp}-${2}]" user@meinedomain.tld < ${temp}
  rm $temp
}

bb_cleanup() {
  echo "> Cleaning variables"
  unset BORG_PASSPHRASE
  unset BORG_RSH
}

main() {
  bb_prep
  bb_run ~/backup_configs configs
  bb_run ~/root/scripts/backup_userdata userdata
bb_cleanup
}

main "$@"

SSH Backupgeschwindigkeit

Um den für mich passenden Kompressionsalgorithmus zu finden, habe ich jeweils ein Kompressionslevel (4) von jedem Algorithmus (lz4, lzma, zlib ) getestet. Dabei wurde de Test mit zwei verschiedenen Backupgrößen druchgeführt. Variante 1 mit ~ 61 MB und Variante 2 mit ~ 70,5 GB. Die dabei verwendete Internetleitung hatte 60 MBit/s down und 6 MBit/s up.