Mit Netz und doppeltem Boden – Backup für den vServer

Wer einen eigenen Server betreibt sollte auf jeden Fall eine Backup-Strategie fahren, um im Falle eines Crashes/Angriffes keine wichtigen Daten zu verlieren. Bis jetzt bestand meine Lösung aus einem NFS-Share, welches mein Hoster zur Verfügung stellte, und einem Scrip, welches den kompletten vServer in ein TAR-Archiv schob, komprimierte und verschlüsselte:


#!/bin/sh
mount $ADRESSEDESNFSSHARES /storage/ -t nfs
systemctl stop mariadb
key=`openssl rand 128 -hex`
echo $key > key
path=/storage/`date +"%d-%m-%y"`
mkdir $path
openssl rsautl -encrypt -inkey public.key -pubin -in key -out $path/key.`date +"%d-%m-%y"`.enc
rm key
tar -cO --exclude='/proc' --exclude='/sys' --exclude='/backup' --exclude='/storage' --exclude='buildroot.img' /* | pbzip2 -c | ccrypt -K $key > $path/backup.`date +"%d-%m-%y"`.tar.bz2.cpt
systemctl start mariadb
umount /storage

Was tut dieses Script? Es generiert einen 128 Bit langen Verschlüsselungsschlüssel, welcher mit einem öffentlichen Schlüssel verschlüsselt wird. Der Verschlüsselungsschlüssel wird zur (symmetrischen) Verschlüsselung des komprimierten TAR-Archives genutzt. Beides wird anschließend auf dem NFS-Share gespeichert. Damit das TAR-Archiv nicht zwischengespeichert werden muss, werden alle Vorgänge (Packen, Komprimieren und Verschlüsseln) durch Pipes miteinander verbunden. Der große Nachteil dieser Lösung ist, dass es sehr zeitaufwändig ist, eine einzelne Datei wiederherzustellen. Zuerst muss das Archiv entschlüsselt, dekomprimiert und entpackt werden, was entsprechend dauern kann.
Auf der Suche nach einer besseren Lösung bin ich über duplicity gestolpert. Das Tool bietet die Möglichkeit, verschlüsselte, inkrementelle und einfach wieder herzustellende Sicherungen zu erstellen.


#!/bin/sh
mount $ADRESSEDESNFSSHARES /storage/ -t nfs
#systemctl stop mariadb
PASSPHRASE='GPGSCHLÜSSELHIERREIN'
SIGN_PASSPHRASE='GPGSCHLÜSSELHIERREIN'
export PASSPHRASE
export SIGN_PASSPHRASE
duplicity --exclude /var/tmp --exclude /tmp --exclude /proc --exclude /sys --encrypt-key 987AAD58 --sign-key 987AAD58 -v 8 / file:///storage > /var/log/backup/backup.log
duplicity remove-older-than 3W file:///storage > /var/log/backup/backup_cleanup.log
#systemctl start mariadbi
unset PASSPHRASE
unset SIGN_PASSPHRASE
umount /storage

Die Handhabung ist relativ einfach. Zunächst erstellt man einen GPG-Schlüssel. Anschließend läuft bei mir obiges Script, gesteuert per Cronjob, alle zwei Stunden durch. Über duplicity remove-older-than 3W werden alle Sicherungen, welche älter als 3Wochen sind, gelöscht. Die Wiederherstellung von Dateien erfolgt über duplicity –file-to-restore. Im Moment macht die Lösung einen ganz soliden Eindruck. Hoffentlich tut sie das im richtigen Ernstfall weiterhin.
Ach ja:
Auf jeden Fall die GPG-Schlüssel und den zugehörigen Key extra sichern! Ohne ist das Backup nicht mehr zu entschlüsseln!

2 thoughts on “Mit Netz und doppeltem Boden – Backup für den vServer

  1. Sieht ganz gut aus. Allerdings frage ich mich, wieso du das Backup überhaupt verschlüsselst. Klar, das NFS-Share kann unsicher sein, aber in deinem konkreten Fall schreibst du, dass das Share von deinem Hoster bereitgestellt wird (dass Netcup sowas tut, wusste ich gar nicht). Auf das Share, sollte es denn vernünftig konfiguriert sein, wovon ich jetzt mal ausgehe, haben also nur du und der Provider Zugriff. Und wenn du dem Provider nicht genug vertraust, dass der da schon keinen Scheiß mit macht – wie hast du dann das Livesystem an sich abgesichert? Theoretisch kann doch jeder Admin mit Vollzugriff auf den Hypervisor eine Rootshell auf der VM spawnen…

  2. NFS geht vollkommen unverschlüsselt über das Netz. Da muss sich nur jemand dazwischen klinken (was vermutlich auch von einem vServer beim Provider geht) und schon kann er alles abgreifen.
    Mit Pech kann jemand IP-Spoofing spielen und auf dein NFS-Share zugreifen. Die Zugriffssteuerung geht über die IP, von der der Zugriff kommt. Das sicherstes Protokoll ist NFS nicht. Da ich nicht weiß, wie die Absicherungen beim Provider sind, gehe ich hier lieber auf Nummer sicher. Einen unbefugten Zugriff bekommst du hier nämlich nicht mit.

    Netcup virtualisiert mit KVM, da kann man nicht mal eben eine Root-Shell starten. Man muss die Platte des vServers irgendwo einhängen, das sollte nicht unbemerkt passieren. Dagegen müsste man die virtuelle Platte vollverschlüsseln. Nur hast du dann das Problem, dass der Server ohne Passwort nicht mehr bootet.

Comments are closed.