SIMBA: Konzept

Anforderungen

Die Anforderungen ergeben sich im Wesentlichen aus den Erfahrungen am WSR in den letzten Jahren:

Zwischen Backup und Archiv wird nicht unterschieden. Das mag daraus begründet sein, dass unser Archiv bislang einfach aus archivierten Backup-Bändern besteht, aber generell ist die Unterscheidung weder einfach noch besonders sinnvoll: Es ist egal, ob eine File-Version, die früher einmal existiert hat, nun nicht mehr existiert, weil sie absichtlich durch eine neuere ersetzt wurde, absichtlich gelöscht wurde, oder durch einen (Hardware-, Software- oder Benutzer-)Fehler verloren gegangen ist. In jedem Fall will man sie wiederherstellen können.
Bei weitem der häufigste Fall, für den ein Backup/Archiv-System benötigt wird, ist das Wiederherstellen von Fileversionen von vor wenigen Tagen. Das muss schnell und einfach funktionieren und sollte vom Benutzer selbst durchgeführt werden können.
Seltener, aber auch immer wieder, werden alte Filebestände benötigt, häufig mehrere Jahre alt, und Metadaten (Filenamen, Zeitpunkt, zu dem die Files existiert haben) sind nicht immer vollständig bekannt. Das muss weniger schnell gehen, kann Eingreifen des Admins erfordern, wichtig sind aber gute Suchmöglichkeiten.
Idealerweise sollte jede Fileversion, die jemals existiert hat, archiviert werden. Dieses Ideal ist wahrscheinlich nicht erreichbar, aber zumindest Fileversionen, die über 24-48 Stunden existiert haben, sollten wieder auffindbar sein.
Das System soll einfach sein. Ich habe eine eine tiefsitzende Abneigung gegen Systeme, die ich nicht verstehe, insbesondere dann, wenn ich ihnen wichtige Daten anvertraue, und dafür verantwortlich bin, diese Daten auch wieder rauszubekommen.
Das System muss mit Datenmengen im Terabyte-Bereich zurecht kommen.
Das System muss die Performance aktueller Hardware ausnützen können.
Es sollte vermieden werden, unveränderte Daten immer wieder zu archivieren.
"Ein Band ist kein Band." Bänder sind nicht extrem zuverlässig, insbesondere, wenn sie lange aufbewahrt werden. Daten sollen daher redundant archiviert werden können.
Integrationsmöglichkeit für Datenbanken und andere Datenquellen, die nicht einfach durch Kopieren einzelner Files gesichert werden können.

Nicht benötigt werden folgende Features:

Standortübergreifende Backups über langsame Leitungen.
Verschlüsselte Backups.

Architektur

Das System besteht aus mehreren "Agents", die jeweils bestimmte Aufgaben haben. Die Abbildung zeigt einen Client (d.h., ein System, von dem Backups erstellt werden sollen) und einen Backup-Server, der die Backups verwaltet.

Collection Agent

Die Zentrale Komponente bildet der "Collection Agent", der in regelmäßigen Abständen (typischerweise täglich), Kontakt zu den Clients aufnimmt, den aktuellen Filebestand festellt, neue bzw. geänderte Files vom Client anfordert und im FS Cache sowie im Catalog speichert.

Der FS Cache hat die von rsync-snapshot bekannte Struktur:

Ein Directory für jeden Zeitpunkt, an dem ein Backup begonnen wurde.
Darunter ein Directory für jeden Client
Darunter die gesamte Directorystruktur des Clients. Files haben die selben Metadaten (insbesondere Owner und Permissions) wie das File am Client), Files, die sich seit dem letzten Backup nicht geändert haben, sind Hardlinks auf das bestehende File.

Da jeder Subtree des FS Cache eine vollständige Kopie des entsprechenden Subtrees am Client ist, kann der FS Cache einfach über Samba oder ein anderes Netzwerk-Filesystem read-only export werden. Restores erfolgen einfach durch Kopieren der Files auf den Client.

Der Catalog enthält die Metadaten aller Files in einer relationalen Datenbank. Das dient einerseits der schnelleren Suche, andererseits dazu, Informationen über bereits auf Band ausgelagerte Dateien zu halten, die nicht mehr im FS Cache vorhanden sind.

Disk Agent

Der Disk Agent muss auf jedem Client installiert werden. Er dient dazu, Informationen über das lokale Filesystem des Clients an den Collection Agent zu übertragen. Im wesentlichen sind das:

ein rekursives Listing eines Directories samt Metadaten
Metadaten und Inhalt eines bestimmten Files

Der Disk-Agent kann konfiguriert werden, dass er bestimmte Directories, von denen kein Backup gewünscht ist (z.B. /proc und /sys auf Linux-Systemen, aber auch z.B. Directories mit Datenbankfiles) ausspart.

Im aktuellen Prototyp wird der DA über SSH gestartet, die Authentifikation erfolgt über Public-Keys. Sollte sich das als zu langsam erweisen, kann Agent auch über eine "nackte" TCP-Verbindung kommunizieren, die dafür notwendige Authentifikation ist aber im aktuellen Prototyp noch nicht implementiert.

Directorylistings und Filedaten werden über unterschiedliche Verbindungen übertragen, was effektives Streaming erleichtert.

Der Disk-Agent übersetzt systemspezifische Daten in ein "allgemeines" Format. Z.B. werden Filenamen vom lokalen Encoding nach UTF-8 übersetzt, und ACLs werden im POSIX-Textformat dargestellt.

Es wäre möglich, statt eines Disk-Agents, der auf ein Filesystem zugreift, einen zu implementieren, der beliebige andere Daten (Datenbanken, etc.) exportiert. Z.B. könnte ein Disk-Agent für Online-Backups einer Oracle-Datenbank folgendes Interface implementieren (bitte das als Beispiel zu verstehen, bei Oracle würde man wahrscheinlich eher RMAN verwenden):

Ein Directory pro Tablespace mit einem Subdirectory pro Datafile und je einem Start/Ende-Markerfile.
Durch Zugriff auf das Start/Ende-Markerfile wird der jeweilige Tablespace in den Backup-Modus bzw. wieder aktiv gesetzt.
Jedes Datafile wird durch ein Directory von Files repräsentiert, die Teile des Datafiles abbilden. Für jeden Teil wird ein eigenes Last-Modified-Datum verwaltet.
Archive-Logs werden als je ein File dargestellt.
Der Collector-Agent sieht nur eine einfache Directory-Struktur, die er einfach rekursiv durchgeht, wodurch er den Disk-Agent dazu veranlasst die jeweil richtigen Tablespaces in den Backup-Modus zu schalten. Nur Teile von Datenfiles, die sich geändert haben, müssen über das Netz übertragen und auf Band geschrieben werden.

In diesem Fall ist das einfache Restore über ein Netzwerkfilesystem natürlich nicht möglich.

Media Agent

Der Media Agent dient dazu, Files auf Bänder (oder andere Wechselmedien) auszulagern.

Er liest Daten über den aktuellen Stand aus dem Catalog, bestimmt anhand seines Regelwerks, welche Files auf welches Band geschrieben werden müssen, und führt das durch.

Aus Performance-Gründen werden Files nicht direkt aus dem FS Cache auf Band kopiert. Speziell bei vielen kleinen Files wäre so nicht sicherzustellen, dass die zum Streamen erforderliche Transferrate erreicht wird. Statt dessen werden in der Media Queue Files sinnvoller Größe (1GB dürfte bauchgefühlmäßig für LTO-3 angemessen sein) im Standard-PAX-Format erzeugt. Diese Files werden dann 1:1 auf Band kopiert. Wahrscheinlich ist es sinnvoll, für die Media Queue eine eigene Disk (bzw. ein RAID-1-Paar) zu reservieren.

Der Media Agent besteht aus zumindest zwei Prozessen mit unterschiedlichen Aufgaben. Wahrscheinlich ist es sinnvoll, ihn in zwei Programme zu splitten ("Archiving Agent" schreibt in die Media Queue, "Media Agent" kopiert von dort auf Wechselmedium).

Auslagerungsregeln

Prinzipiell können die Auslagerungsregeln beliebig komplex werden, wobei folgende Daten zur Verfügung stehen:

Die Metadaten aller Fileversionen.
Die Zuordnung von Fileversionen zu Files
Ob eine Fileversion sich auf einem Band befindet, und wenn ja, auf welchem
Eine Zuordnung von Bändern zu Pools
Ob das Band im Laufwerk, im Bandroboter, on-site oder off-site ist.

Folgende Regeln könnten unsere aktuellen Bedürfnisse abdecken:

Archiv

Das Archiv dient dazu, alle Files, für die das sinnvoll ist (in erster Näherung alle außer Oracle-Datenbanken, tmp-Directories, etc.), "ewig" aufzubewahren. Das kann wie folgt erreicht werden:

Erstelle eine Liste aller Files im aktuellen FS Cache.

Exkludiere ev. Files, die nicht archiviert werden sollen (Anm.: Die meisten solchen Files sind vermutlich gar nicht im FS Cache, da sie bereits vom DA ausgeschlossen werden können).

Exkludiere ev. Files, die nur während eines CA-Runs existiert haben (wahrscheinlich temporäre Files).

Bestimme alle Fileversionen, die noch nicht auf Band gesichert wurden.

Wenn sich alle existierenden Fileversionen am gleichen Band befinden, aber nicht auf dem Band, das gerade geschrieben werden soll, selektiere auch die aktuelle Version.

Offsite-Backup für Disaster-Recovery

Ein volles Backup sollte sich off-site befinden, um im Fall eines Komplettausfalls ein Ersatzrechenzentrum aufbauen zu können. Austausch erfolgt (derzeit) wöchentlich.

Erstelle eine Liste aller Files im aktuellen FS Cache.

Exkludiere ev. Files, die für ein Offsite-Backup nicht benötigt werden. (Anm.: Das ist gefährlich - das Offsite-Backup wird nicht regelmäßig getestet, und wenn im Ernstfall wichtige Files fehlen, hat man ein Problem).

Bestimme die aktuelle Fileversion, aber nur wenn diese noch nicht auf ein Band in diesem Pool gesichert wurde, oder wenn sie sich auf einem Band befindet, das recycelt werden soll.

Man kann entweder immer das älteste Band, das sich off-site befindet, zum Recyclen markieren, oder einen intelligenteren Algorithmus verwenden - z.B. das Band, auf dem sich die wenigsten noch-aktuellen Fileversionen befinden.

Datenbank-Backups

Datenbank-Backups in Form von Datenfiles sind hauptsächlich für Disaster-Recovery und zum Clonen einer Datenbank für Migrationstest sinnvoll. Ein älteres Datenbank-Backup samt Software sollte sich restoren lassen, sofern die Datenbank-Software auf der aktuellen Hardware/OS-Kombination noch läuft. Wegen des relativ hohen Aufwands wird das nur in Notfällen gemacht. Die aktuelle Backup/Archiv-Strategie könnte einfach weiterverwendet werden:

Erstelle eine Liste der aktuellen Fileversionen der entsprechenden Datenbank.

Jeder Pool enthält eine fixe Anzahl von Bändern, das jeweils älteste wird recycelt. Ein Band pro Quartal wird in den Archiv-Pool verschoben.

Mengengerüst

Filesystem-Backups: Die Filesystembackups benötigen derzeit ca. 50-100 GB an täglichen Incrementals (Domino-Server nicht eingerechnet), ca. 1-2 Wochen sollten sich also auf einem LTO-3-Band ausgehen. D.h., beim derzeitigen Datenaufkommen muss mit 2-4 Archivbändern pro Monat gerechnet werden (derzeit: 11 LTO-1-Bänder).

Für Lotus Notes müsste eine geeignete Strategie gefunden werden, täglich die Datenbankfiles zu archivieren ist sicherlich sinnlos. Mehr als ein Band pro Monat sollten wir eigentlich nicht brauchen.

Bei Datenbanken hängt der Verbrauch stark von der Archivierungsstrategie und Nutzung ab. Bei Online-Sicherung aller Archive-Logs habe ich mal vor längerer Zeit 1700 GB (also ca. 2 Bänder) pro Monat geschätzt. Wenn wir beim Quartalsmäßigen Backup bleiben, ließe sich das auf 1 Band/Quartal reduzieren.

Insgesamt sollten wir beim aktuellen Datenaufkommen mit ca. 6 Bändern pro Monat für's Archiv auskommen. Laufende Kosten ca. € 400 / Monat? (+ Strom, Arbeit, etc.)

Für die Bänder in der Wollzeile brauchen wir einen Pool fixer Größe, der regelmäßig recycelt wird. 3 TB sollten auf 4 Bändern Platz haben, u.U. möchte man mehr Bänder zur einfacheren Organisation.

SIMBA - Simple Integrated Multiplatform Backup and Archive