ftplicity und duplicity: Ein paar Anmerkungen (nicht nur für Debian/lenny)

Die meisten Leute, die irgendwo einen (mehr oder weniger) billigen Server gemietet haben, werden es kennen: Für Backups kriegt man eher selten IBM’s Tivoli TSM, sondern meistens einfach nur ein bißchen Filespace auf einem FTP-Server. Um da dann Backups zu machen, gibt es einfache Varianten, wie z.B. Backup Manager, der auf recht einfache Weise volle oder inkrementelle Sicherungen von Dateien in Tarballs macht (auf Wunsch auch verschlüsselt) und sogar von sich aus MySQL-Datenbanken und SVN-Repositories sichern kann. Das größte Problem ist, daß das Programm keine Datenbank der gesicherten Dateien führt - gerade im Fall inkrementeller Sicherungen kann das Wiederherstellen eines bestimmten Standes einer Datei ganz schön anstrengend werden.

Die Kombination aus duplicity und ftplicity springt hier in die Bresche und überzeugt durch zusätzliche Features wie z.B. die Tatsache, daß in inkrementellen Sicherungen dank der Verwendung der rsync-Libraries bei Veränderungen in Dateien nur die Blöcke gesichert werden, die sich wirklich geändert haben. Zum Thema Installation und Konfiguration dieses „dynamischen Duos” (das konnte ich mir jetzt nicht verkneifen) gibt es ungefähr 1000 verschiedene Anleitungen - teilweise vielleicht nicht ganz aktuell, aber dafür gibt es ja Manpages und sonstige Dokumentationen. Ein paar Dinge, die mir aufgefallen sind will ich hier mal dokumentieren (auch für mich, falls ich in die Verlegenheit komme, mich damit nochmal auseinandersetzen zu müssen):

  • In Debian/etch findet sich nur eine recht alte 4.x-Version - und die kann noch keine asynchronen Uploads, sprich, immer, wenn ein Backup-Volume erzeugt wurde, lädt das Programm dieses erst hoch, bevor es das nächste Volume erzeugt. Die Version 5.16, die das kann, gibt es bei backports.org. Um das zu aktivieren, reicht es, in die conf-Datei (Achtung, Wortspiel!) des jeweiligen Backup-Profils die folgende Zeile aufzunehmen:
DUPL_PARAMS="$DUPL_PARAMS --asynchronous-upload "
  • Legt man als root-Benutzer das Verzeichnis /etc/ftplicity an (und setzt entsprechend restriktive Berechtigungen, da stehen ja Paßwörter drin) spart man sich den Stress, Konfigurationsdateien in /root zu haben.

  • Es gibt ein duplicity-Paket, aber keines für ftplicity - kein Wunder, denn letzteres ist nur ein einzelnes Shellscript.

  • Es macht durchaus Sinn, mehr als nur ein Backup-Profil anzulegen - z.B. um nach Aufgaben des Server zu unterteilen. Um dann alle Profile wie z.B. home, www, system und mail hintereinander zu sichern, kann man eine Schleife der folgenden Form verwenden:

for profile in $(cd /etc/ftplicity && ls ); do
  ftplicity $profile backup
done
  • duplicity kennt den Parameter „–full-if-older-than” - aber den muß man nicht verwenden, vielleicht will man einen Vollbackup ja auch etwas früher starten, einen anderen Bericht generieren oder noch im selben Skript purgen.

  • Die exclude-Files (noch ein Wortspiel!) werden als globbing flielists eingebunden. An etwas versteckterer Stelle in der Manpage findet man dann die Sache mit den Plus- und Minuszeichen. Oder anders: Wenn man die Verzeichnisse /export/www/site13 und /export/www/site15 sichern, den Rest von /export/www aber ignorieren will, dann setzt man SOURCE='/export/www' und befüllt die exclude-Datei folgendermaßen:

+ /export/www/site13
+ /export/www/site15
- /export/www
  • ftplicity backup führt pre- und post-Backup-Skripte aus, „ftplicity full” nicht (warum auch immer).

  • Die Standard-Volume-Größe von 5MB ist so ca. Faktor 20 zu klein - das hängt aber auch stark von der Anbindung und der Leistungsfähigkeit des Servers ab, auf dem die Dateien landen sollen, und des eigenen Systems ab. Der beherzte Einsatz eins Einzeilers wie z.B. watch 'ls -lh /tmp/duplicity*; ps -ef | grep [n]cftpput' oder ähnlichem ist hilfreich, die beste Größe zu finden und bewahrt einen auch davor, den temporären Backup-Space zu klein zu dimensionieren.

  • Und für meine eigene Schusseligkeit: DUPL_PARAMS erwartet anscheinend ein Blank am Ende.

Die ganzen Standardphrasen über das Testen von Restores und das Reporting spare ich mir. Und hey, wenn der FTP-Space des eigenen Anbieters aufgrund seltsamer DNS-Probleme manchmal einfach „unbekannt verzogen” ist, dann hat man halt kein Backup. In dem Fall kann man sich dann ja z.B. mit Beethoven, Sonate Nr. 26, Der Abschied ablenken.

Update 25.08.2009: Einen recht großen Performancegewinn bringt es, wenn man jedem Backupset in den DUPL_PARAMS ein eigenes --archive-dir spendiert. Darin liegen dann lokal Signaturen und Manifeste etc.