Verschlüsselte Backups mit Duply auf einen HiDrive oder anderswohin

Bei dem inzwischen zur Telekom gehörenden Web-Hoster Strato bekommt man immer mal wieder – auch gerade anlässlich der Funkausstellung – einen HiDrive zum Sonderpreis: Ein Jahr lang kostet der Cloud-Speicher im Netz mit 100 GB nur einen Euro. Das ist ein interessantes Angebot, denn der HiDrive lässt sich über diverse Protokolle ansprechen und versteht sich auch auf rsync, was ihn für ernsthafte Backup-Zwecke prädestiniert. Deshalb soll es hier darum gehen, wie man per rsync und Duply Backups anfertigt – auf den HiDrive oder einen andern Server. Auch das NAS im Heimnetz tut’s, sofern sich dort rsync installieren lässt.


Zunächst: rsync ist „sowohl ein Netzwerkprotokoll als auch ein unter der GPL stehendes Programm zur Synchronisation von Daten, meistens über ein Netzwerk (Wikipedia). Wobei der Begriff „Synchronisation“ Missverständnisse provoziert. Rsync hält nicht mehrere Verzeichnisse synchron (wie zum Beispiel die Dropbox-Software), sondern synchronisiert immer nur in einer Richtung, im Netzwerk von einem Client (also dem Rechner, der regelmäßig Backups durchführen soll) zu einem entfernten Server (der die Backups speichert). Der große Vorteil von rsync besteht in der Bandbreiten-schonenden Übertragung. Es werden nur geänderte Dateien gesendet, und von diesen auch nur geänderte Teile.

Lässt man rsync über Secure Shell, kurz ssh, laufen, dann erfolgt die Datenübertragung verschlüsselt. Client und Server müssen beide rsync und ssh beherrschen. Der HiDrive kann beides von Hause aus. Auf einem anderen Server oder Ihrem NAS müssen Sie rsync und OpenSSH ggf. selbst installieren. Wenn Sie dann noch ihre Backups vor dem Versenden mit Pretty Good Privacy verschlüsseln, dann kann sie auch der neugierige Admin des entfernten Servers nicht einsehen.

Im hier vorgestellten Szenario soll ein unter Debian oder Ubuntu laufender Linux-Webserver (im Folgenden „Client“ genannt) jede Nacht verschlüsselte, inkrementelle Backups vom Dokumenten-Verzeichnis /var/www sowie von Datenbanken über einen SSH-Tunnel auf einen HiDrive sichern. Inkrementell bedeutet: Es wird nicht jeden Tag ein volles Backup erstellt; nur geänderte Dateien werden übermittelt. Außerdem sollen – innerhalb eines wählbaren Zeitfensters – mehrere Versionen derselben Datei vorgehalten werden. So lassen sich heute irrtümlich gelöschte oder überschriebene Dateien mit den Versionen von gestern wieder herstellen. Ein Monat Vorhaltezeit soll genügen. Für all dies sorgt Duply, ein vergleichsweise einfach konfigurierbares Frontend für die vielseitige, selbst aber nur schwer konfigurierbare Backup-Software Duplicity, die wiederum rsync für die eigentliche Daten-Übertragung nutzen kann. Unter Linux lassen sich die benötigten Tools problemlos installieren, beispielsweise unter Debian und Ubuntu:

# apt-get update && apt-get upgrade
# apt-get install rsync ssh gnupg duply

Bei einer automatisierten Backup-Lösung sind Passwort-Abfragen sinnlos, wenn niemand vor dem Rechner sitzt. Die Authentifizierung erfolgt deshalb Schlüssel-basiert, also über Keyfiles. Das passende Schlüsselpaar kann man sich einfach generieren. Wenn Sie Duply mit Root-Rechten ausführen wollen (weil auch Dateien kopiert werden sollen, die Ihnen nicht gehören), müssen Sie zuvor mit su oder sudo su ebenfalls Root-User werden, damit das Schlüsselpaar für Root erstellt wird:

# ssh-keygen

Im folgenden Dialog können Sie die standardmäßig vorgeschlagenen Antworten mit Enter quittieren – auch die Fragen nach der Passphrase, da zu deren Eingabe bei jedem Backup ein Mensch vor der Maschine sitzen müsste (oder auch nicht – Stichwort ssh-agent, aber das führt für unseren Anwendungsfall zu weit). Nach erfolgreicher Generierung findet sich  im Verzeichnis /root/.ssh/ das Schlüsselpaar id_rsa  und id_rsa.pub – der private und der öffentliche Schlüssel. „rsa“ kennzeichnet nach dem RSA-Verfahren erstellte Schlüssel. Wenn Sie den DSA-Algorithmus gewählt haben, steht „id_dsa“ im Dateinamen. Und damit zum Server.

Administriert wird der HiDrive im Browser über ein recht komfortables grafisches Frontend. Die Zugangsdaten haben Sie von Strato erhalten. Wenn Sie den HiDrive noch für andere Zwecke verwenden, empfiehlt es sich, mit Hilfe des Dateimanagers für Backups einen eigenen Ordner einzurichten. Der Pfad zu den Dateien sieht dann für rsync wie folgt aus: rsync.hidrive.strato.com/users/account-xxxxxxx/backups – account-xxxxxx ersetzen Sie mit Ihrem Benutzernamen.

Anschließend wird unter Einstellungen > Kontenverwaltung der Zugang konfiguriert. Benutzen Sie den Standardbenutzer oder richten Sie einen neuen Benutzer nur für Backups ein. Dann:

Rsync-Zugriff aktivieren: Unter Konteneinstellungen im Menüpunkt Admin- und Protokollrechte den Eintrag rsync über SSH aktivieren. Nicht benötigte Protokolle kann sicherheitshalber deaktivieren.

Public Key hinterlegen: Von Kontoeinstellungen zu OpenSSH-Schlüssel wechseln. Dort per Upload-Formular – anders geht es anscheinend nicht – den öffentlichen Schlüssel id_rsa.pub hochladen.

Damit sollte rsync über SSH bereits einsatzfähig sein. Probieren Sie im Terminal es aus, spiegeln Sie einen Ordner auf den HiDrive:

# rsync --delete -avze ssh /var/www account-xxxxx@rsync.hidrive.strato.com:/users/account-xxxxx/backups
The authenticity of host 'rsync.hidrive.strato.com (85.214.3.70)' can't be established
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)?

Diese Rückfrage bekommen Sie, wenn Sie sich zum ersten Mal mit dem HiDrive oder einem anderen Server verbinden. Sagen Sie ja (sehr vorsichtige Menschen vergleichen zuvor den „Fingerabdruck“), so wird der Server in die Datei ~/.ssh/knownhosts eingetragen. Künftig läuft die rsync-Verbindung dann ohne jegliche Nachfragen ab. Mit anderen Worten: Bevor Sie Backups automatisiert ablaufen lassen, müssen Sie sich einmal per rsync – oder direkt mit ssh – beim entfernten Server anmelden, um ihn dem eigenen System bekannt zu machen.

GnuPG-Key erzeugen: Nachdem die rsync-Verbindung funktioniert, gilt es nun noch, auf dem Client Duply einzurichten. Da Duply unsere Backup-Daten verschlüsseln soll, wird ein Key benötigt. Wer noch keinen hat, muss ihn sich mit dem Programm GnuPG erzeugen:

# gpg --gen-key

Benutzen Sie im folgenden Dialog die vorgegebenen Werte, wählen Sie eine lange, nicht erratbare Passphrase und geben Sie Ihre Namen und Email ein. Am Ende sollten sich im Verzeichnis ~/.gpg/ die Schlüssel-Dateien befinden. Auch hier wieder der Hinweis: Wird Duply mit root-Rechten ausgeführt, sucht es den GnuPG-Key im Verzeichnis /root/.gpg/ – schieben Sie also ihr Schlüsselverzeichnis dorthin, wenn es noch nicht existiert.

Duply benötigt für seine Konfigurationsdatei die ID des öffentlichen Schlüssels. Der Befehl

# gpg -k

spuckt drei Zeilen aus, darunter eine, die mit pub (public – öffentlich) gekennzeichnet ist und etwa wie folgt aussieht, wobei ich die ID fett hervorgehoben habe:

pub 2048R/7F9106F4 2011-02-06

Nun können wir die Erzeugung eines Backup-Profils namens hidrive für Duply anstoßen. Wiederum gilt: Wenn duply mit root-Rechten laufen soll, dann erzeugen Sie das Profil mit Root-Rechten:

# duply hidrive create
 Congratulations. You just created the profile 'hidrive'.
 The initial config file has been created as
 '/etc/duply/hidrive/conf'.
 You should now adjust this config file to your needs.

Die Konfigurationsdatei /etc/duply/hidrive/conf öffnen wir jetzt mit dem Editor unserer Wahl und passen sie an. Nachfolgend habe ich nur jene Zeilen aufgeführt, die für unser rsync-Szenario geändert werden müssen:

GPG_KEY='der_key_siehe_oben'
GPG_PW='meine_gpg_passphrase'
TARGET='rsync://account-xxxxx@rsync.hidrive.strato.com/users/account-xxxxx/backups'
SOURCE='/var/www'

Anders als beim originalen rsync-Befehl oben steht hinter rsync.hidrive.strato.com kein „:“ mehr!

Belässt man ansonsten die Standardeinstellungen, führt Duply jeden Monat ein Vollbackup durch, speichert ansonsten nur geänderte Dateien und behält die Backups einen Monat lang – oder länger, wenn darin noch Daten liegen, auf die sich spätere Backup-Sets beziehen. Natürlich kann man auch längere Fristen angeben und öfter Vollbackups erstellen lassen (was die Wiederherstellung einfacher macht) – das hängt davon ab, wie viele Daten man sichert und wie groß der Backup-Space ist. Die 100 GB beim Ein-Euro-HiDrive können sehr schnell zur Neige gehen.

Duply erlaubt zudem, Aufgaben zu definieren, die vor und nach dem eigentlichen Backup ablaufen. In diesem Szenario sollen Datenbank-Inhalte gesichert werden. Zu diesem Zweck wird im Editor eine Text-Datei /etc/duply/hidrive/pre mit einem Shell-Script angelegt, das in einer Schleife für alle MySQL-Datenbanken einen mysqldump mit kurzen Atempausen zwischendurch ausführt. Die Dumps werden dann innerhalb des Ordners gespeichert, dem das Backup gilt. In meinem Szenario führt root das Backup aus, so dass die Dumps zwar im Dokumenten-Verzeichnis des Webservers gespeichert werden, aber für neugierige Web-Surfer nicht einsehbar sind, weil sie root gehören:

#!/bin/sh
for db in $(mysql -u root -p geheim -e 'show databases' -s --skip-column-names | grep -v 'information_schema');
     do
          mysqldump -u root -p streng-geheim --databases $db > /var/www/$db.sql;
          sleep 10;
     done

Sie können nun mit dem Kommando

# duply hidrive backup

ein erstes Backup anstoßen und in der Konsole beobachten. Je nach Umfang des Backups (zu Beginn wird immer ein Voll-Backup gemacht, es gibt ja noch keine Daten) kann das allerdings lange dauern. Ohnehin wollen Sie in Zukunft das Backup nicht von Hand veranlassen. Also gilt es, einen Cron-Job anzulegen, damit das Backup jede Nacht angestoßen wird. Und wieder Hinweis: Wenn der Cron-Job unter dem Benutzer Root laufen soll, verschaffen Sie sich zuerst Root-Rechte, sonst wird er unter mit Ihren eigenen Benutzer-Rechten ausgeführt. Dann

# crontab -e

Fügen Sie der Datei eine neue Zeile mit folgendem Inhalt zu:

30 2 * * * /usr/bin/duply hidrive backup_verify_purge --force >/dev/null 2>/var/log/duply/hidrive.log

Künftig wird sich Duply um 2.30 Uhr in der Nacht still und leise (stdout wird auf /dev/null/ umgeleitet, stderr in ein Logfile) ans Werk machen und ein Backup durchführen, die Integrität des Backups kontrollieren (was zu irritierenden Fehlermeldungen führen kann, wenn Dateien auf dem Datenträger in der Zwischenzeit schon wieder verändert wurden) und veraltete Backups löschen. Leitet man die Ausgaben von Duply nicht um, so wird cron jeden Tag eine interne Mail mit der Ausgabe von Duply zustellen, was vielen Admins vielleicht sogar lieber ist.

Sie können und sollten das kontrollieren: Der Befehle status gibt Auskunft über den Stand der Backup-Dinge; gerade wenn’s übers Netz zu einem entfernten Host geht, kann auch mal etwas schiefgehen.

# duply hidrive status

Sollte Duply tatsächlich melden: „Warning, found incomplete backup sets, probably left from aborted session“, dann kann man sich diese kaputten Datensätze mit cleanup anzeigen lassen – oder mit der Option –force auch gleich zur Löschung schreiten:

# duply hidrive cleanup –force

Wie ein Backup wiederhergestellt wird: Mit dem Befehl restore holen Sie ein Voll-Backup zurück, mit fetch einzelne Ordner oder Dateien – und das auch in einer älteren Version. Der Zusatz 15D holt beispielsweise den Stand von vor 15 Tagen zurück. Lassen Sie ihn weg, erhalten Sie die letzte Version:

duply hidrive restore /ort/der/wiederherstellung 15D
duply hidrive fetch pfad/zur/Datei/relativ/zum/backup/ordner /ort/der/wiederherstellung

Der Ort der Wiederherstellung darf noch nicht existieren. Duply weigert sich sonst, Dateien zurückzuspielen. Um ein versehentliches Überschreiben auszuschließen, weigert sich Duply/Duplicity auch, eine Wiederherstellung am ursprünglichen Speicherort vorzusehen. Sollten Sie beim Fetchen eine Fehlermeldung bekommen, lesen Sie hier nach.

Letzte Amtshandlung: Sobald Duply funktionstüchtig eingerichtet ist, sollte der Konfigurationsordner /etc/duply/hidrive an einen sicheren Ort kopiert werden, damit Sie im Falle einer Havarie des Clients von einem anderen Rechner wieder auf die Backups zugreifen können. Hüten Sie ihn wie Ihren Augapfel, denn darin ist auch ihr GPG-Schlüssel.

2 comments on “Verschlüsselte Backups mit Duply auf einen HiDrive oder anderswohin”

  1. Sobald Duply funktionstüchtig eingerichtet ist, sollte man den Konfigurationsordner an einen sicheren Ort kopieren, damit Sie im Falle einer Havarie des Clients von einem anderen Rechner wieder auf die Backups zugreifen können. Dazu brauchen Sie natürlich auch Ihren ~/.gpg/-Ordner mit den besonders sensiblen Schlüsseldaten. Hüten Sie ihn wie Ihren Augapfel.

    Sie schrieben „auch Ihren ~/.gpg/-Ordner“ – welche(n) Ordner sonst noch?

  2. @Karl Marx: Den Konfigurationsordner /etc/duply/name und dazu noch den gpg-Ordner des Nutzers, unter dem duply läuft. Das war gemeint. Vielleicht unklar formuliert. Auf jeden Fall aber auch nicht richtig. Habe gerade noch einmal auf meinem Server mit Duply nachgeschaut:

    Erstens heißt der gpg Ordner nicht .gpg, sondern .gnupgp.
    Zweitens speichert Duply die Schlüssel auch in seinem eigenen Konfigurationsordner, so dass es reicht, diesen zu sichern und wie den sprichwörtlichen Augapfel zu hüten.

    Ich korrigiere das im Text.

Schreibe einen Kommentar