Verschlüsselte Backups mit duply

Weit über ein Jahr ist es her, daß ich über die Erstellung von verschlüsselten Backups mit Hilfe von ftplicity geschrieben habe. Mittlerweile erstelle ich die Backups mit duply und duplicity. duply ist ein Frontend für duplicity und erleichert ein wenig die Arbeit.
Grundsätzlich gehe ich immer von einem klassischen Debian aus, dem entsprechend müssen ein paar Pakete zusätzlich installiert werden.

aptitude install python-dev librsync-dev ncftp

Damit sind die Grundvoraussetzungen geschaffen und wir können uns duplicity holen:

cd /usr/src
wget http://code.launchpad.net/duplicity/0.6-series/0.6.09/+download/duplicity-0.6.09.tar.gz
tar xfz duplicity-0.6.09.tar.gz
cd duplicity-0.6.09
python setup.py install

Das ging schnell, jetzt wird es noch schneller!

cd /usr/src
wget http://downloads.sourceforge.net/project/ftplicity/duply%20%28simple%20duplicity%29/1.5.x/duply_1.5.2.3.tgz
tar xfz duply_1.5.2.3.tgz
cd duply_1.5.2.3
cp duply /usr/local/bin

Aus dem Archiv die Datei duply entpacken und in /usr/(s)bin oder /usr/local/(s)bin kopieren.
Grundsätzlich ist duply nun funktionsbereit, es fehlt jedoch nocht der GPG-Schlüssel. Ohne diesen läuft nichts.

gpg --gen-key

Die Standardvorgabe für die Schlüsselart ist in Ordnung und kann mit [ENTER] bestätigt werden. Die Schlüsselgröße 2048 ist auch in Ordnung, wer mehr will, kann auch auf 4096 gehen. Der Schlüssel soll niemals ungültig werden, also bestätigen wir mit y die Gültigkeit „läuft niemals ab“. Zum Schluß noch Angaben wie Name und eMail und das Ganze mit O bestätigen.
Jetzt wird der Schlüssel generiert. Unter Umständen kann das mal ein paar Minuten dauern, je nach dem, wieviel auf dem Server los ist. Die Nummer des generierten Schlüssels müssen wir uns merken und im Folgenden in die Konfiguration von duply einfügen.
Hier eine Beispielausgabe von gpg mit einer zufälligen Schlüselnummer:
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 73FA48DA marked as ultimately trusted
public and secret key created and signed.

Nun erstellen wir eine Grundkonfiguration:

duply bkprofil create

bkprofil ist ein frei wählbarer Name des Backup-Profils.
Nun wurde, sofern wir duply als root ausgeführt haben, im ordner /root/.duply der Ordner bkprofil angelegt. Innerhalb dieses Ordners ist nun die Konfigurationsdatei conf. Hier wollen wir ein paar Einstellungen vornehmen.

nano /root/.duply/bkrpofil/conf

Wichtig sind hier die ID vom GPG-Key (GPG_KEY) und das entsprechende Passwort (GPG_PW). Bei den GPG_OPTS schalte ich die als Standard vorgegebene bzip2-Komprimierung mit Level 9 ein. (GPG_OPTS=‘–compress-algo=bzip2 –bzip2-compress-level=9′)
In der Konfiguration sind Beispiele für das „Target“ aufgeführt, also der Ziel-Server, auf dem das Backup abgelegt werden soll. Am weitesten verbreitet dürfte FTP sein, daher geben wir hier als Ziel einen FTP-Server vor: TARGET=’ftp://SERVER/VERZEICHNIS‘
TARGET_USER und TARGET_PASS sind denke ich selbsterklärend. ;-)
SOURCE gibt an, welcher Ordner gesichert werden soll. Entweder man trifft hier schon eine Vorauswahl, z.B. /srv oder man nimmt das gesamte Dateisystem ‚/‘ und verfeinert die Auswahl später. Ich nehme hier SOURCE=’/‘ und spezifiziere später in einer anderen Datei die zu sichernden Dateien.
MAX_FULL_BACKUPS stellt die Anzahl der vorgehaltenen vollen Backups an. Je nach verfügbarem Speicherplatz und eigenen Wünschen kann hier gewählt werden, sinnvoll ist denke ich der Bereich zwischen 1 und 3.
Wenn MAX_FULLBKP_AGE gesetzt ist, wird automatisch bei erreichen dieser Zeit ein Vollbackup erstellt, anderenfalls ein inkrementelles Backup. Wird MAX_FULLBKP_AGE auf 2W gesetzt, wird beim ersten Aufruf von duply ein voller Backupsatz erstellt. Beim  Aufruf z.B. am nächsten Tag wird der volle Satz erkennt und ein inkrementelles Backup gestartet. Sind nun 2 Wochen abgelaufen, wird wiederum ein neues, volles Backup angelegt.
Mit VOLSIZE wird die Größe der einzelnen Archivdateien eingestellt. Meine Favoriten sind 500 oder 750, also 500MB bzw. 750MB. Selbstverständlich kann hier auch mehr angegeben werden.

Würde jetzt ein Backup gestartet, würde der komplette Server gesichert werden, das ist nicht unbedingt immer gewünscht. Daher lege ich nun eine weitere Datei an, um mein Backup zu verfeinern.

nano /root/.duply/bkrpofile/exclude

+ /home
+ /var/www
- /

Diese drei Zeilen geben an, daß die Ordner /home und /var/www gesichert werden sollen. Das geschieht natürlich inklusive der jeweiligen Unterordner. Der Ordner / wiederum soll nicht gesichert werden, d.H. der gesamte Rest wird ausgeschlossen.

Nun steht dem ersten Backup nichts mehr im Wege.

duply bkprofil backup

Nun wird das bzip2-komprimierte und mit GPG verschlüsselte Backup erstellt und die Archive auf den FTP-Server geschoben.
Ist das Backup durchgelaufen, schauen wir uns einmal das Ergebnis an:

duply bkprofile status

Found primary backup chain with matching signature chain:

-------------------------
Chain start time: Sun Sep 19 09:02:01 2010
Chain end time: Sun Sep 19 09:02:01 2010
Number of contained backup sets: 1
Total number of contained volumes: 7
 Type of backup set:                            Time:      Num volumes:
 Full         Sun Sep 19 09:02:01 2010                 7
-------------------------
No orphaned or incomplete backup sets found.

Das Backup wurde mit 7 Archiven erstellt, keine unvollständigen Backupsätze gefunden. Sobald inkrementelle Backups angelegt wurden, werden diese hier entpsrechend angezeigt.
Den genauen Inhalt des Backups können wir uns wie folgt anschauen:

duply bkprofile list

Jedoch empfehle ich die Umleitung in eine Datei, da sie einfacher zu durchsuchen ist.

duply bkprofile list > output.txt

Zum Schluß automatisieren wir unsere Backups noch mit cron.

crontab -e

30 0 * * * /usr/local/bin/duply bkprofile purge-full --force
30 1 * * * /usr/local/bin/duply bkprofile backup

Hier wird jetzt jeden Tag um 0:30h das Kommando purge-full durchgeführt, d.H. sobald mehr als MAX_FULL_BACKUPS Vollbackupsätze vorhanden sind, werden die älteren Sätze gelöscht. Der Schalter –force gibt an, daß die Dateien nicht nur gelistet sondern auch gelöscht werden sollen.

Um 1:30h startet das eigentliche Backup.

So weit, so gut! Die Backups laufen und wir hoffen, daß wir sie nicht wirklich benötigen werden, doch wie man an seine Dateien im Ernstfall wieder heran kommt, beschreibe ich in der Fortsetzung.