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.
- ausführbar sein (
- 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.
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt