Marco Gabriel

Konfiguration (FTP)

Als nächstes legen wir das Verzeichnis /etc/duply an, wo wir die Konfiguration der Sicherungsjobs (=Profile) hinterlegen. Existiert das Verzeichnis nicht, legt duply die Konfiguration unter dem Home Verzeichnis des Benutzers an.

mkdir -p /etc/duply

Dann erstellen wir ein neues Sicherungsprofil mit dem Namen ftpbackup.

duply ftpbackup create

Nun sollte in /etc/duply/ftpbackup eine Datei namens conf existieren, die man mit einem beliebigen Editor später anpassen kann.

Bevor wir die Konfiguration des Sicherungsprofils jedoch anpassen, müssen wir einen GnuPG Key erstellen, mit dem unsere Backups später ver- und wieder entschlüsselt werden können.

gpg --gen-key

Die Defaults kann man übernehmen, sofern man sich unsicher ist. Man sollte hier eine sichere Passphrase verwenden, die einerseits so sicher ist, dass sie nicht erraten werden kann, die man andererseits aber auch in 10 Jahren noch weiss. Ohne Passphrase wird's schwierig, wieder an seine Daten zu kommen.

Als Ausgabe sollte nun etwas in dieser Art zu sehen sein:

gpg: key --> A44D2D30 <-- marked as ultimately trusted
public and secret key created and signed.

Die erzeugten Schlüssel liegen nun im GnuPG Keystore unter $HOME/.gnupg. Um eine Liste aller dort hinterlegten Schlüssel anzuzeigen kann man gpg --list-keys verwenden. Es gibt auch schöne grafische Frontends für GPG, auf die ich hier jedoch nicht näher eingehen möchte.

Nun passen wir die Konfigurationsdatei unter /etc/duply/ftpbackup/conf mit einem editor an und tragen dort den Schlüssel (Das ist der Key A44D2D30 aus dem vorangegangenen Schritt) sowie die gewählte Passphrase ein.

# gpg key data (for symmetric encryption comment out GPG_KEY)
GPG_KEY='A44D2D30'
GPG_PW='Mein Backup ist ein Backup, welches ich 2010 erstellt habe!'

Die Zugangsdaten für den FTP Server werden ebenfalls in dieser Datei hinterlegt.

TARGET='ftp://benutzername:passwort@ftp.backupserver12345.de/backupdir'

Weiterhin muss der Source Pfad eingestellt werden. Wenn nur Daten eines bestimmten Verzeichnisses gesichert werden sollen, kann man dies direkt hier eintragen. In der Regel aber geht es um mehrere Verzeichnisse direkt unterhalb von /, weshalb hier / auch meist die richtige Einstellung sein dürfte.

SOURCE='/' 

Damit aber nicht unnötigerweise Dateien gesichert werden, die bei einer Wiederherstellung auch keinen Sinn ergeben, sucht Duplicity eine Datei namens /etc/duply/ftpbackup/exclude und liest hier heraus die Dateien und Pfade, welche von der Sicherung ausgeschlossen werden sollen. Diese Datei könnte zum Beispiel so aussehen:

/dev
/sys
/mnt
/tmp
/proc
/media
/cdrom
/lost+found

Kleiner Hinweis am Rande: Es handelt sich um eine per --exclude-globbing-filelist eingebundene Liste. Näheres dazu gibt's in der Duplicity Manpage.

Nun werden alle Verzeichnisse unterhalb von / gesichert ausser die oben aufgeführten.

Duply kennt noch zwei weitere automatisch verarbeitete Dateien:

/etc/duply/<profilname>/pre ist ein Shell Script, welches vor einer Datensicherung ausgeführt wird. Hier sollten beispielsweise Datenbankdumps oder vorbereitende Massnahmen durchgeführt werden. Ebenso kann man eine /etc/duply/<profilname>/post verwenden, welche nach einem Backup ausgeführt wird. Man sollte darauf achten, dass die pre und post Scripts als ausführbare Dateien gekennzeichnet sind, da sie sonst nicht ausgeführt werden.

Nun ist alles soweit vorbereitet.

Konfiguration für Amazons S3

Wer von seinem Provider keinen Backup FTP Space gestellt bekommt, braucht ja auch nicht gleich zu verzweifeln. Amazon mit seinem Simple Storage Service (S3) schafft hier relativ gut und günstig Abhilfe. Im Grunde genommen funktioniert die Konfiguration sehr ähnlich der obigen, allerdings lauern ein paar Fallen.

Ausser einem Amazon AWS Konto und einem Zugang zum S3 sollte ein Schlüsselpaar erstellt werden um dem Backup-Script Zugriff zu gewähren. Außerdem muss das Paket python-boto mittels aptitude installiert werden (aptitude install python-boto). Man sollte unbedingt auf eine aktuelle Version von Boto achten, da erst in neueren Versionen europäische Storage Center unterstützt werden.

In der Konfigurationsdatei unter /etc/duply/<profilname>/conf sind folgende Zeilen für das Backup auf Amazon S3 wichtig:

TARGET='s3+http://awskey:passwort@bucketname/backupdirname'

und

DUPL_PARAMS="$DUPL_PARAMS --s3-use-new-style --s3-european-buckets --asynchronous-upload "

Die Option --s3-new-style muss angegeben werden, damit --s3-european-buckets funktioniert. --asynchronous-upload ist als experimentell gekennzeichnet, kann aber gerade bei langsamen Uplinks den Backup-Prozess beschleunigen, da während dem Upload bereits das nächste Backup-Archiv erstellt wird. Wer jedoch eine schnelle Leitung besitzt, viel Zeit hat oder unbedingt auf Nummer Sicher gehen möchte, sollte auf --asynchronous-upload verzichten.

Keine Sorge, auch wenn oben s3+http:// steht: Boto überträgt grundsätzlich per HTTPS. Als Bucketname muss etwas eindeutiges verwendet werden, da jeder Bucketname nur ein einziges Mal bei Amazon verwendet werden darf. Sofern der Bucket noch nicht existiert wird er automatisch angelegt, ebenso wie der backupdirname.

Ready? Backup!

Das erste Backup kann nun gestartet werden mit einem einfachen

/usr/bin/duply ftpbackup backup

Da beim ersten Lauf noch kein altes Backup existiert, wird dieses Backup automatisch ein vollständiges sein. Dies kann nun eine Weile dauern. Bei jedem weiteren Aufruf wird Duply dann entscheiden, ob ein inkrementelles Backup genügt, oder ob es mal wieder Zeit für ein vollständiges Backup ist. Die entsprechenden Intervalle lassen sich ebenfalls in der Konfigurationsdatei des Profils eintragen.

Automatisch, Baby.

Nun gilt es, diesen Schritt zu automatisieren, so dass jede Nacht ein Backup durchgeführt wird. Hierfür kann man unter /etc/cron.daily/duply ein Shell Script anlegen (und ausführbar machen) in dem man täglich den obigen Befehl ausführt.

Duply kann auch mehrere Befehle nacheinander durchführen, beispielsweise um zuerst ein Backup zu erzeugen (backup), dann das Backup nochmals zu prüfen (verify) und anschließend alte, abgelaufene und nicht mehr benötigte Archive zu entfernen (purge --force, ohne die Angabe von --force werden keine Daten gelöscht!). Man braucht nur alle Kommandos mit einem "_" zu verknüpfen:

/usr/bin/duply ftpbackup backup_verify_purge --force

Wenn dies nun eingetragen ist, sollte jede Nacht automatisch ein neues, verschlüsseltes Backup erzeugt und auf dem FTP Server abgelegt werden. Ob dies auch funktioniert, kann man nach den ersten Backups mit einer kurzen Überprüfung herausfinden:

/usr/bin/duply ftpbackup status

Darüber hinaus sollte in regelmässigen Abständen auch testweise eine Rücksicherung durchgeführt werden, um für den Notfall gerüstet zu sein. Denn Backup ist schön, aber Restore noch viel schöner .

Gib sie wieder her... Restore tut not!

Ein Restore funktioniert ähnlich einem Backup. Folgendes Beispiel nimmt die Datensicherung des Profils ftpbackup und restauriert diese unter dem Pfad /testrestore, allerdings auf dem Stand von vor 5 Tagen (5d). Gibt man den Stand (hier: 5d) nicht an, so wird der aktuell gesicherte Stand zurückgeholt.

/usr/bin/duply ftpbackup restore /testrestore 5d

Die kompletten Möglichkeiten von Duply sieht man mit einem duply usage auf der Shell.

Fast(!) fertig.

Nach der Einrichtung des Backups sollte man unbedingt daran denken, den erzeugten GnuPG Schlüssel noch an einem anderen Ort aufzubewahren. Sollte nämlich der durch das Backup gesicherte Rechner einen Totalverlust erleiden, ist natürlich auch der GnuPG Schlüssel weg. Er liegt dann zwar noch im Backup, aber an dieses kommt man natürlich ohne Schlüssel nicht mehr ran. Der komplette $HOME/.gnupg Ordner sollte als tar.gz gesichert und an einem sicheren Ort aufbewahrt werden.

Duply und Duplicity sind eine schöne Lösung um ein Backup eines Rootservers auf einem FTP Space abzulegen. Während Duplicity die Funktionalität bereitstellt macht Duply das ganze bedienbar.

Kommentare, Anregungen, Erweiterungen oder Verbesserungen? Ab in die Kommentare damit.