Grundidee

Grundidee des Offsite Backup

Ich hatte das Problem, dass ich meine Daten gern backupen möchte. Da die Datenmenge (ca. 200 GB) für Tapes zu gross ist, kam eigentlich nur ein Backup auf Hard-Disk in Frage.

Mein Ziel war dabei weniger ein Backup im Sinne von langzeit Wiederherstellbarkeit oder Archivierung von Daten, sondern vielmehr ein Backup für einen Desaster-Fall (Totalausfall der Raid, Brand des Systems, ...).

Um auch für Desaster wie Hausbrand gewappnet zu sein, war schnell klar, dass die Daten ausser Haus gelagert werden sollen. Meine erste Lösung war, die Daten monatlich auf eine Disk zu kopieren und im Büro zu lagern. <g> Doch das war einfach zu mühsam und in einem Monat verändern sich doch sehr viele Daten und gemäss Murphy's Law [1] würde ein Desaster natürlich genau einen Tag vor dem nächsten Backup zuschlagen.

Also musste eine automatische, täglich laufende Lösung her.

Zum Glück war ich mit dem Problem nicht allein und zusammen mit einem Leidensgenossen (huhu Efan!) wurde das Offsite Backup konzipiert und implementiert.

Das Problem schlussendlich war natürlich nicht die Machbarkeit sondern viele kleine Unwegsamkeiten... aber das macht private Projekte erst richtig spannend! :)

Technische Grundpfeiler

Da die Daten auf einem Fremd-System gelagert werden, war eine Grundprämisse, dass die Daten verschlüsselt abgelegt weden müssen. Ausserdem sollte die "Urbetankung" der Backup-Disk jeweils beim Eigner der Daten erfolgen, damit nicht über 150 GB gesynched werden mussten...

Ausserdem war von Anfang an klar, dass auch der Datentransfer möglichst verschlüsselt und beidseitig stark authentisiert ablaufen soll.

Die Plattform war mit Linux auch von Anfang an fix. Einziger Pferdefuss: Während ich SuSE verwende, läuft auf der Gegenstelle ein Gentoo.

Durch die Patches von SuSE am cryptofs scheiterte der erste Versuch die Urbetankten Disks auszutauschen und im Gast-System zu mounten. :(

Besser ging's dann mit EncFS [2]. Dieses setzt auf User-Space Filesytem FUSE [3] auf und ist über die Distro-Grenze hinweg portabel.

EncFS hat für uns auch noch den Vorteil, dass nur der User, der das Volume mountet auch den Inhalt sieht. Das bietet auf einem Gast-System zwar nur Minimalen Schutz (der Eigentümer ist root und kann somit während das EncFS gemountet ist eh alles) aber besser als gar nix. :-p

Als die Verschlüsselung der Daten auf dem Gast-System geklärt war, stellte sich die Frage, wie man das mounten, unmounten und synchen der Daten machen könnte. Da wir zumindest das Passwort für das EncFS möglichst geheim halten wollten, war die Idee, über einen verschlüsselten Kanal das Passwort zu übertragen schnell geboren.

Und mit dieser Idee war dann auch klar, dass eine kleine Client-Server Applikation geschrieben werden musste.

Aus dieser Konstellation haben sich dann die Skripte für den Caller und den Listener rauskristalisiert.

Verschlüsselung der Datenübertragung

Da der ganze Datentransfer zwischen Caller und Listener verschlüsselt ist (beide Teile verwenden OpenSSL [4]), können Parameter (welche z.B. das Passwort zum Mounten des Krypto-FS darstellen) nicht einfach mitgesnifft werden.

Um Man-in-the-Middle [5] Attacken zu verhindern, besitzen sowohl der Caller als auch der Listener X.509 Zertifikate. Beim Verbindungsaufbau prüfen beide, ob das präsentierte Zertifikat den Erwartungen (Subject und Issuer) entspricht. Nur wenn diese Prüfung erfolgreich ist, werden Daten/Kommandos/Parameter ausgetauscht.