Skip to content

Backup mit duply und duplicity

Niemand will Backup. Alle wollen Restore.

(Kristian Köhntopp zitiert einen Vertriebler - Fachbegriffe der Informatik #125)

Regelmäßige Backups sind wichtig und auch durch redundante Systeme wie RAIDs nicht zu ersetzen; ganz abgesehen davon, daß bei einem RAID 1 gerne die - meistens ja zum selben Zeitpunkt wie die erste in Betrieb genommene - zweite Platte beim notwendigen Rebuild zusammenbricht, schützt ein RAID auch nur gegen Datenverlust durch Ausfall einer Festplatte, aber weder gegen versehentliches oder böswilliges Löschen, Überschreiben oder Verändern von Daten, noch kann es gegen einen fatalen Schaden des gesamten Systems (Brand, Diebstahl, …) schützen. Backups sollten daher

  • regelmäßig durchgeführt werden,
  • versioniert sein (so daß man einen längeren Zeitraum zurückgehen kann) und
  • off-site transferiert werden können.

Zumindest dann, wenn man keine Kontrolle über die Infrastruktur hat, auf der die Backups gespeichert und über die sie transportiert werden, sollten Backups auch verschlüsselt sein. Diese letzte Anforderung ist typisch für sog. "Rootserver", also Mietserver, zu denen bei üblichen Angeboten auch ein sog. "Backupspace", also Speicherplatz auf einem Storage gehört, auf den zumeist nur per (unverschlüsseltem) FTP zugegriffen werden kann. Selbst wenn man dem Provider und seinen Mitarbeitern vertraut, kann man nicht ausschließen, daß auch Dritte - andere Kunden, … - zumindest den unverschlüsselten Datenverkehr zwischen dem zu sichernden Server und dem Storage "belauschen" können. Wenn man seine Backups also unverschlüsselt überspielt, kann die gesamte Konfiguration samt aller Paßworte usw. usf. mitgelesen werden.

Schließlich gibt es eine letzte Anforderung für sinnvolle Backups: sie sollten, einmal eingerichtet, möglichst wenig Aufwand bedeuten, optimalerweise automatisiert sein, denn nur dann werden sie auch wirklich regelmäßig durchgeführt.

Alle zuvor genannten Anforderungen erfüllt das Tool duplicity, für das die c’t bereits anno 2006 ein Frontend namens ftplicity entwickelt hat, das nunmehr unter dem Namen duply weiterentwickelt wird. duply unterscheidet sich u.a. dadurch von ftplicity, daß es nicht nur die Konfiguration der Übertragung via FTP unterstützt, sondern auch auf anderem Weg (was dann auch die Namensänderung erklärt).

duplicity sichert Dateien und Verzeichnisse in (nicht gepackte!) tar-Archive, verschlüsselt diese vermittels GnuPG und überträgt die Sicherungen in kleinen Häppchen auf verschiedenen Wegen (lokal, FTP, SCP, rsync, …) auf das Sicherungsmedium; dabei werden inkrementielle Backups über den rsync-Algorithmus erstellt, d.h. nicht alle veränderten Dateien gesichert, sondern ggf. nur ein diff, was wiederum Platz und Bandbreite spart. duplicity dürfte in den meisten Distributionen paketiert sein, duply ist es in Debian ab Squeeze, kann aber in jedem Fall trivial installiert werden.

Eine mögliche Umsetzung für einen Mietserver sieht - unter Debian Lenny - so aus:

  • duplicity und ncftp installieren: aptitude -r install duplicity ncftp
  • duply (in /usr/local/bin) installieren:
cd /tmp
wget -O duply_1.5.4.2.tgz http://sourceforge.net/projects/ftplicity/files/duply%20%28simple%20duplicity%29/1.5.x/duply_1.5.4.2.tgz/download
tar -xzf duply_1.5.4.2.tgz 
cp duply_1.5.4.2/duply /usr/local/bin/
rm duply_1.5.4.2.tgz 
rm -r duply_1.5.4.2
  • Alternativ (Debian Squeeze): aptitude -r install duply
  • Da der gesamte Server gesichert werden soll, läuft der Backupprozess am besten mit Root-Rechten. Wir brauchen jetzt also einen GPG-Key für root und richten dann das Backup ein:
cd /root
gpg --gen-key
  • Wenn nicht genug Entropie vorhanden ist, um den Key zu erzeugen, empfiehlt es sich, bspw. durch mehrere größere Downloads für Netzwerkverkehr und Belastung der Festplatten zu sorgen, um den Pool aufzufüllen. Key-ID und Paßwort des erzeugten Schlüssels benötigt man im nächsten Schritt zur Einrichtung des Backups; der Name des Backups kann frei gewählt werden:
duply *NAME* create
vim .duply/*NAME*/conf
  • In der Konfigurationsdatei sind nun zumindest einzutragen
    • die ID des erzeugten GPG-Schlüssels (GPG_KEY),
    • das Paßwort desselben (GPG_PW),
    • das Backup-Ziel (FTP-Server und ggf. Verzeichnis, Benutzername, Kennwort: TARGET, TARGET_USER, TARGET_PASS) und
    • den Pfad, der gesichert werden soll (im Zweifel "/": SOURCE).

    Für die Einzelheiten und fortgeschrittene Konfigurationsmöglichkeiten sei auf die Kommentare innerhalb der Datei und die Dokumentation von duplicity und duply verwiesen.

  • Als nächstes erstellt man eine Liste der Dateien, die nicht gesichert werden sollen, die mindestens spezielle Verzeichnisse wie /dev und /proc enthalten sollte: vim .duply/NAME/exclude
/dev/\*
/proc/\*
/sys/\*
/tmp/\*
/var/tmp/\*
/var/run/\*
  • Danach kann man noch Scripts hinterlegen, die vor oder nach dem Backuplauf ausgeführt werden; bspw. kann es sich vor dem Backup empfehlen, Datenbanken zu dumpen. Diese Scripts heißen dementspechend pre und post, können zum Beispiel Shellscripts sein und müssen
    • ausführbar sein (chmod 700 .duply/NAME/pre) und
    • einen entsprechenden shebang (#!/bin/bash) enthalten.
  • Wenn das alles paßt, kann man nunmehr sein erstes Backup starten: duply *NAME* backup
  • Danach sollte man das komplette Verzeichnis .duply (das dann auch eine Kopie des GPG-Schlüssels enthält) sichern (nicht auf den Backupspace, sondern an einen sicheren Ort!).
  • Schließlich kann man noch in die Crontab von root einen entsprechenden Eintrag einfügen:
00 5 \* \* \* /usr/local/bin/duply *NAME* backup
00 6 1 \* \* /usr/local/bin/duply *NAME* full && /usr/local/bin/duply *NAME* purge --force

Fertig. Viel Erfolg!

In gleicher Weise ist es möglich, weitere Backups zu definieren, die bspw. nur /home oder /etc (oder /var/mail …) sichern, das dann aber häufiger.

Trackbacks

Netz - Rettung - Recht am : Backups in die Cloud (duply und S3)

Vorschau anzeigen
Eigentlich wollte ich schon vor gut drei Jahren, im Januar 2013, über dieses Thema schreiben, als ich die ersten Backup-Jobs dieser Art eingerichtet habe, aber irgendwie ist aus dem angefangenen Entwurf nie ein fertiger Blogeintrag geworden. - Nun denn, a

Netz - Rettung - Recht am : Backupkonzepte

Vorschau anzeigen
Je mehr wir uns auf Computer verlassen und wesentliche Teile unseres Lebens, unser Erinnerung nur noch digital existieren, desto wichtiger wird der Schutz dieser Daten sowohl gegen unbefugten Zugriff als auch gegen Verlust oder mutwillige Zerstörung. Ich

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

HTML-Tags werden in ihre Entities umgewandelt.
Markdown-Formatierung erlaubt
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Identicon/Ycon Autoren-Bilder werden unterstützt.
Formular-Optionen
tweetbackcheck