Backups

Für eine anständige Backup-Strategie bin ich schon fast so lange am überlegen wie für meine Groupware-Verwaltung. Nachdem ich mir extra dafür eine externe 500 GB Festplatte gekauft hatte, fehlte nur noch die passende Softwarelösung. Neidisch schaut man im ersten Moment auf Apple's TimeMachine. Rein Objektiv ist dies aber auch nichts anderes als ein Inkrementelles Backup mit kurzen Iterationszeiten und einer netten GUI. Alternativen für Linux wie Flyback sind vorhanden. Allerdings ist dies nicht die einzige Möglichkeit eines sinnvollen Backups.

Fakt ist wohl, ein Backup sollte möglichst nicht jedes mal eine eins-zu-eins Kopie anlegen, da so viel zu viel Speicher verbraucht wird. Lösung sind Inkrementelle oder Differenzielle Backups. So werden nur die Änderungen gespeichert die sich verändert haben. Fast jede Lösung bietet dieses Konzept mittlerweile an. Außerdem wollte ich ein Backup auf Datei-Ebene und nicht auf Partitionsebenen wie es zum Beispiel das Tool dd anbietet. Da ich denke so Flexibler bin und außerdem glaube ich nicht das Inkrementelle Backups auf Partitionsebene möglich ist.

Zuerst plante ich ein Backup mit einem Selbstgeschriebenden Skriptes. Über die Linux-Boardmittel lassen sich eine Vielzahl der der Anforderungen wie Verschlüsselung und Komprimierung recht einfach implementieren. Allerdings wenn man alle Möglichkeiten mit allen kombinieren möchte so wird es irgendwann richtig komplex. So habe ich meine ersten Versuche verworfen und plante mit einem umfangreichen Backup-Programm wie BoxBackup oder Bacula. Hier habe ich aber auch recht schnell erkannt das diese für große Netzwerke ausgelegt sind und für meinen kleinen Laptop etwas überdimensioniert sind. Etwas einfaches musste her!

Über Chaosradio bin ich auf ZFS gestoßen. Ein Filesystem mit einer unglaublichen Feature-Liste. Angefangen von automatischer Größen-Anpassung von Partitionen über automatische Komprimierung bis hin zu gesicherter Konsistenz des Dateisystems bietet es alles was man sich wünschen kann. ZFS bietet auch die Möglichkeit von Snapshots auf Block-Ebene an. Man kann die Daten, die sich geändert haben, einfach über die alten drüber kopieren und anschließend ein Snapshot machen. So hat man im Grunde jedes mal ein Vollbackup obwohl man nur die geänderten Blöcke speichern muss. Leider kommt ZFS aus der Solaris-Welt und kann in den Linux-Kernel im Moment wegen Lizenzproblemen nicht integriert werden. Es existiert zwar eine FUSE-Erweiterung, aber alles noch recht Beta. Das Risiko wollte ich leider nicht beim Backup eingehen und musste mich so nach Alternativen umschauen.

Das System mit den Snapshots hat mir aber gefallen und so bin ich auf das recht populäre Tool rsnapshot gestoßen. Das Programm setzt auf Hardlinks auf. Bei normalen (Soft-)Links hat man eine Datei und erstellt dann Referenzen auf diese Datei. Löscht man eine Referenz interessiert das niemanden. Löscht man die ursprüngliche Datei werden alle Referenzen ungültig. Bei Hardlinks referenziert man nicht auf eine Datei sondern auf ein INode-Eintrag. Also sozusagen eine Ebene Tiefer. Der Vorteil ist, alle Hardlinks sind gleichberechtigt. Die eigentlichen Daten werden erst gelöscht, wenn kein Hardlink mehr darauf verweist. Das Prinzip von rsnapshot ist dadurch recht einfach: Man kopiert das letzte Backup mittels Hardlinks in ein neues Verzeichnis und ändert dann über rsync die veränderten Dateien. So erhält man jeden Tag ein Vollbackup welches nur den Speicherplatz der Änderungen verbraucht.

Ein weiters sehr nützliches Feature ist die Möglichkeit eigene Scripte (z.B. um ein Datenbankdump zu erstellen) in das Backup einzubinden. Und wenn man zum Beispiel einen zweiten Computer mit sichern will, so ist es möglich Daten von diesem über ssh+rsync zu hohlen. Somit sichere ich mein Laptop mein Server und die Datenbank auf meinem Server recht einfach mit nur einem Programm

Leider kann rsnapshot, anders wie ZFS nur auf Datei-Ebene arbeiten. So wird eine Datei in der sich nur ein Buchstabe ändert komplett neu übertragen. Auch wird es nicht erkannt wenn man ein Verzeichnis oder eine Datei umbenennt. Auch in diesem Fall wird die Datei neu abgespeichert. Aber wenn man sich der Problematik bewusst ist, stört sie kaum.

Programme wie Storebackup umgehen das Problem indem sie zu jeder Datei Prüfsummen anlegen und diese vergleichen. Allerdings ergibt sich so ein worst-case-Aufwand von O(n^2) da ja jede Checksumme erst einmal erstellt, und dann mit jeder Datei verglichen werden muss. Man sieht schon, diese Lösung braucht um einiges länger als mein rsnapshot. (180 GB in ca 10 Minuten täglich bei einem diff von gerade mal einigen hundert MB). Außerdem wollte ich auch ein gut getestetes Konzept und habe mich so für das weit verbreitete rsnapshot entschieden satt das (evtl gar nicht mehr weiter entwickelte) Storebackup.

Und nun die Zuschauerfrage: Wie macht ihr eure Backups? Ich denke jeder der am Computer arbeitet braucht ein Backup, da Datenverlust nur eine Frage des Wann ist. Und wenn die Dateien nur einmal pro Woche auf DVD gebrannt werden. Auf jeden Fall würde mich euer Setup interessieren. Gerne auch in einem eigenen Blog-Post bei euch. Verlinkt euch einfach in den Kommentaren!

Groupware Protokolle

Wer träumt nicht von einer zentralen Verwaltung seiner PIM-Informationen? Groupware-Systeme unterstützten diesen Prozess indem sie die Daten zentral verwaltet und verschiedene Schnittstellen anbietet. In vielen Fällen wird eine Groupware nach ihrem Web-Frontend bewertet. Leider spielt diese eigentlich nur eine sehr untergeordnete Rolle. Das Hauptproblem konzentriert sich darauf, möglichst viele Clients mit dem System verbinden zu können. Deshalb möchte ich kurz einige interessante Techniken auflisten um den Austausch der Daten zu Realisieren.

Formate

Zumindest hier zeichnet sich langsam ein Standard ab. Für Termine hat iCalendar (oder kurz ical) langsam den älteren Konkurrenten vCalendar abgelöst. Mit iCalendar lassen sich allerdings nicht nur Termine sondern auch todo's oder Journaleinträge damit verwalten. Leider ist das Format nicht ganz so schön (man ist ja langsam überall XML gewohnt) aber zumindest die meisten Datenfelder werden überall verstanden. Da man aber auch selbst Erweiterungen definieren kann, ist es doch möglich das Details in verschiedenen Anwendungen anders verstanden werden. Bei Kontakten hat sich vCard durchgesetzt, wofür weitgehend das selbe wie bei iCalendar gilt.

Protokolle

Leider sind dies ja nur Dateiformate. Meistens möchte man ja aber diese Daten zentral hinterlegen und mit verschiedenen Clients darauf zugreifen. Dazu sind einige Protokolle nötig, die diesen Transport realisieren. Hier möchte ich auch mein eigentliches Hauptaugenmerk legen.

Email

Hier ist es noch am einfachsten. POP ist Tot. IMAP ist Standard. Viel mehr muss man dazu nicht sagen. Interessant sind allerdings einige Erweiterungen für IMAP. Einmal wäre da IMAP-IDLE. Dabei meldet sich der Client am Server an und senden anschließend nur ab und zu keep-alive-Pakete. Der Server hingegen antwortet sobald eine neue Mail eintrifft. So hat man ein wunderbaren Mail-PUSH ohne jeden Aufwand. Erwähnenswert ist noch Sieve. Sieve. Stieve ist eine Programmiersprache in der sich Regeln wie zum Beispiel Abwesenheitsnachrichten, oder Spamregeln definieren lassen. Außerdem ist meistens nicht bekannt das man mit IMAP auch komplexe ACL's definieren kann. So ist es möglich ein Postfach auch mehreren Personen zugänglich zu machen.

Kalender und Kontakte

XML-RPC

Einige Projekte wie eGroupware oder PHProject setzten auf XML-RPC zur Synchronisation. Zwar lässt sich so sehr einfach dagegen programmieren aber leider ist dies immer sehr Spezifisch auf die einzelne Anwendung. Deshalb finde ich diese Idee nicht sonderlich toll. Lieber ein standardisiertes Protokoll für alle!

WebDav

Eine sehr einfache Möglichkeit ist der Einsatz von WebDav wie er auch von subversion benutzt wird. WebDav ist eine Erweiterung zu HTTP, die es ermöglicht Dateien auch hochzuladen. So kann man einfach die jeweilige Datei (ical oder vcard) auf dem Server plazieren und diese herunter laden oder eben wieder schreiben. Das Problem ist nur: Jedes mal muss die gesamte Datei mit allen Einträgen heruntergeladen werden und bei Änderungen auf dem Server übertragen. Das kostet Zeit und macht verteiltes Arbeiten recht schwierig.

GroupDAV

GroupDav ist eine kleine Erweiterung zu WebDav die einfach nur festlegt jeder Event oder Kontakt liegt in einer einzelnen Datei in einem jeweiligen Unterordner. So muss immer nur eine Datei übertragen werden. Diese Idee finde ich noch von allen die beste Möglichkeit da man so auch einfach den Ordner lokal für offline Arbeit zwischenspeichern kann.

IMAP

Kolab definiert versteckte IMAP Ordner. Der jeweilige Client speichert Kontakte oder Termine als Email in den jeweiligen versteckten Ordner mit entsprechendem XML-Anhang. Die gesamte Kommunikation läuft so über IMAP Ordner. Ist eine nette Idee, allerdings finde ich den Gedanken sehr unschön meine Kontakte und Termine als XML-Anhang an eine versteckte Email ranzukleben. Ist irgendwie sehr umständlich und sicher nicht Sinn der Sache.

SyncML

SyncML hat sich ja längst auf allen Handys festgesetzt und auch erste Plugins für Desktop-Anwendungen sind verfügbar. Dazu beigetragen hat sicherlich funambol (früher Sync4J). Dies ist ein freier SyncML-Server der von Google-Anwendungen über Groupdav bis hin zum IPhone alles miteinander Syncen kann.

Kalender only

CalDav ist spätestens seit es Google in seinem Kalender unterstützt etwas populärer als GroupDAV. Es basiert ebenfalls auf WebDav allerdings kann man auch komplexere Abfrage-Queries an den Server stellen. Das macht es einerseits natürlich etwas effektiver als GroupDav allerdings auch komplexer zu Implementieren. Für Apache gibt es übrigens ein CalDav-Modul. Leider muss man Apache dafür neue übersetzten (was ich auf einem Server sehr ungern tue).

Kontakte only

Hier ist sicherlich eine der wichtigsten Lösungen LDAP. Fast jedes Programm kann auf LDAP zugreifen. Es bietet sehr gute Such Möglichkeiten und ist einfach zu erweitern. Leider hat man hier immer das Problem das man auf ein LDAP nur lesend zugreifen kann. Will man Einträge hinzufügen oder bearbeiten muss dies manuell auf dem Server geschehen. Deshalb wird von vielen Groupware-Systemen LDAP nur als Read-Only-Verzeichnis genutzt. Die eigentlichen Änderungen laufen über andere Protokolle. Serverseitig werden diese dann ins LDAP überführt.

Sonstiges

Eigentlich erwarte ich von einer Groupware, dass sie mehr als nur Emails, Kontakte, Termine und Todos unterstützt. Allerdings sieht es hier noch schlechter aus, als in den anderen Bereichen. Wünschenswerte Features wären zum Beispiel RSS (was leider meistens nur read-only für den Client ist. Also sprich der Client kann dem Server nicht mitteilen welche Items ich gelesen habe. Kennt hier jemand eine Lösung??), XMPP, IRC (Wäre doch Klasse wenn der komplette Verlauf, zum jeweiligen Kontakt, zentral abgespeichert wird) oder auch Bookmarks (ganz im grandiosen (neuen) delicious.com-Style). Aber von solchen Ideen sind wir wohl noch ähnlich weit entfernt wie zu dieser Vision: Assoziative Gedächtnishilfe für mobile Datensammler

Ich hoffe ich konnte kurz einen Überblick über mögliche Techniken geben. Vielleicht kanntet ihr ja das ein oder Andere noch nicht. Sollte ich was vergessen haben, einfach in den Kommentaren melden! Zum Schluss mein Wunsch-Setup: IMAP (mit IDLE und Sieve), GroupDav, LDAP (read-only) und Funambol-Connector. SOGo (ein Fork von OpenGroupware.org) bietet mir zwar genau das, allerdings habe ich mit dem Kompilieren des Objective-C Quellcodes einige Probleme ;-).

Anmerkung 1: Ich konnte (noch) nicht alle Produkte und Protokolle ausprobieren, deshalb sind die Kommentare alle nur persönliche Empfindungen

Anmerkung 2: Mir ist aufgefallen ich verlinke sehr wenig auf andere Seiten. Ich hab diesmal sehr viel (vor allen) auf Wikipedia verlinkt. Findet ihr das besser?