<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">



<html>
  <head>
  <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
  <title>SIMBA: Konzept</title>
  <link rel="stylesheet" href="doc.css" type="text/css" />
  </head>
  <body>
    <h1> SIMBA - Simple Integrated Multiplatform Backup and Archive </h1>
    <div class="section">
      <h2> Anforderungen </h2>
      <p>
	Die Anforderungen ergeben sich im Wesentlichen aus den
	Erfahrungen am WSR in den letzten Jahren:
      </p>
      <ul>
	<li>
	  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.
	</li>
	<li>
	  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.
	</li>
	<li>
	  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.
	</li>
	<li>
	  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.
	</li>
	<li>
	  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.
	</li>
	<li>
	  Das System muss mit Datenmengen im Terabyte-Bereich zurecht
	  kommen.
	</li>
	<li>
	  Das System muss die Performance aktueller Hardware ausnützen
	  können.
	</li>
	<li>
	  Es sollte vermieden werden, unveränderte Daten immer wieder zu
	  archivieren.
	</li>
	<li>
	  "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.
	</li>
	<li>
	  Integrationsmöglichkeit für Datenbanken und andere
	  Datenquellen, die nicht einfach durch Kopieren einzelner Files
	  gesichert werden können.
	</li>
      </ul>
      <p>
	Nicht benötigt werden folgende Features:
      </p>
      <ul>
	<li>
	  Standortübergreifende Backups über langsame Leitungen.
	</li>
	<li>
	  Verschlüsselte Backups.
	</li>
      </ul>
    </div>
    <div class="section">
      <h2> Architektur </h2>
      <div>
	<img src="arch.png" alt="Deployment und Datenfluss" />
      </div>
      <p>
	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.
      </p>
      <div class="section">
	<h3> Collection Agent </h3>
	<p>
	  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.
	</p>
	<p>
	  Der FS Cache hat die von 
	  <a href="http://www.hjp.at/programs/rsync-snapshot/index.en.html">rsync-snapshot</a> 
	  bekannte Struktur:
	</p>
	<ul>
	  <li>
	    Ein Directory für jeden Zeitpunkt, an dem ein Backup begonnen
	    wurde.
	  </li>
	  <li>
	    Darunter ein Directory für jeden Client
	  </li>
	  <li>
	    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.
	  </li>
	</ul>
	<p>
	  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.
	</p>
	<p>
	  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.
	</p>
      </div>
      <div class="section">
	<h3> Disk Agent </h3>
	<p>
	  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:
	</p>
	<ul>
	  <li> ein rekursives Listing eines Directories samt Metadaten </li>
	  <li> Metadaten und Inhalt eines bestimmten Files </li>
	</ul>
	<p>
	  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.
	</p>
	<p>
	  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.
	</p>
	<p>
	  Directorylistings und Filedaten werden über unterschiedliche
	  Verbindungen übertragen, was effektives Streaming erleichtert.
	</p>
	<p>
	  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.
	</p>
	<p>
	  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):
	</p>
	<ul>
	  <li>
	    Ein Directory pro Tablespace mit einem Subdirectory pro
	    Datafile und je einem Start/Ende-Markerfile.
	  </li>
	  <li>
	    Durch Zugriff auf das Start/Ende-Markerfile wird der
	    jeweilige Tablespace in den Backup-Modus bzw. wieder aktiv
	    gesetzt.
	  </li>
	  <li>
	    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.
	  </li>
	  <li>
	    Archive-Logs werden als je ein File dargestellt.
	  </li>
	  <li>
	    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.
	  </li>
	</ul>
	<p>
	  In diesem Fall
	  ist das einfache Restore über ein Netzwerkfilesystem natürlich
	  nicht möglich. 
	</p>
      </div>
      <div class="section">
	<h3> Media Agent </h3>
	<p>
	  Der Media Agent dient dazu, Files auf Bänder (oder andere
	  Wechselmedien) auszulagern.
	</p>
	<p>
	  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.
	</p>
	<p>
	  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.
	</p>
	<p>
	  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).
	</p>
      </div>
    </div>
    <div class="section">
      <h2> Auslagerungsregeln </h2>
      <p>
	Prinzipiell können die Auslagerungsregeln beliebig komplex
	werden, wobei folgende Daten zur Verfügung stehen:
      </p>
      <ul>
	<li> Die Metadaten aller Fileversionen.  </li>
	<li> Die Zuordnung von Fileversionen zu Files </li>
	<li> Ob eine Fileversion sich auf einem Band befindet, und wenn
	ja, auf welchem </li>
	<li> Eine Zuordnung von Bändern zu Pools </li>
	<li> Ob das Band im Laufwerk, im Bandroboter, on-site oder off-site ist.</li>
      </ul>
      <p>
	Folgende Regeln könnten unsere aktuellen Bedürfnisse abdecken:
      </p>
      <div class="section">
	<h3> Archiv </h3>
	<p>
	  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:
	</p>
	<p>
	  Erstelle eine Liste aller Files im aktuellen FS Cache.
	</p>
	<p>
	  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).
	</p>
	<p>
	  Exkludiere ev. Files, die nur während eines CA-Runs existiert
	  haben (wahrscheinlich temporäre Files).
	</p>
	<p>
	  Bestimme alle Fileversionen, die noch nicht auf Band gesichert
	  wurden.
	</p>
	<p>
	  Wenn sich alle existierenden Fileversionen am gleichen Band
	  befinden, aber nicht auf dem Band, das gerade geschrieben
	  werden soll, selektiere auch die aktuelle Version.
	</p>
      </div>
      <div class="section">
	<h3> Offsite-Backup für Disaster-Recovery </h3>
	<p>
	  Ein volles Backup sollte sich off-site befinden, um im Fall
	  eines Komplettausfalls ein Ersatzrechenzentrum aufbauen zu
	  können. Austausch erfolgt (derzeit) wöchentlich.
	</p>
	<p>
	  Erstelle eine Liste aller Files im aktuellen FS Cache.
	</p>
	<p>
	  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).
	</p>
	<p>
	  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.
	</p>
	<p>
	  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.
	</p>
      </div>
      <div class="section">
	<h3> Datenbank-Backups </h3>
	<p>
	  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:
	</p>
	<p>
	  Erstelle eine Liste der aktuellen Fileversionen der
	  entsprechenden Datenbank.
	</p>
	<p>
	  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.
	</p>
      </div>
    </div>
    <div class="section">
      <h2>Mengengerüst</h2>
      <p>
	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).
      </p>
      <p>
	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.
      </p>
      <p>
	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.
      </p>
      <p>
	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.)
      </p>
      <p>
	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.
      </p>
    </div>
  </body>
</html>