Baculas Stand

was gegenwärtig implementiert und funktionsfähig ist und was nicht.

Was implementiert ist

• Job-Steuerung
  • Sicherung/Wiederherstellung im Netzwerkes unter der Regie eines zentralen Director-Prozess.
  • automatische Ausführung von Jobs nach einem festgelegten Zeitplan.
  • Terminplanung für mehrere Jobs zur gleichen Zeit.
  • die Möglichkeit einen oder mehrere Jobs zur gleichen Zeit auszuführen.
  • zeitliche Staffelung der Jobs entsprechend ihrer Priorität.
  • Console Programm als Benutzer-Schnittstelle zum Director-Dienst. Eine shell-, Qt4-GUI-, GNOME-GUI und wxWidgets-Version sind derzeit verfügbar. Die Qt4-Version der Console, Bacula Administration Tool, kurz bat genannt, bietet viele zusätzliche Funktionen gegenüber der shell-Version.

• Sicherheit
  • die Verifikation der Dateien, die zuvor in das Catalog-Verzeichnis aufgenommen wurden, erlaubt eine Funktionalität wie sie das Programm Tripwire hat (Intrusion Detection).
  • die Authentifizierung der Komponenten (Dienste) untereinander durch CRAM-MD5 Passwörter.
  • eine konfigurierbare TLS (ssl)-Verschlüsselung zwischen den einzelnen Komponenten.
  • bei Bedarf die Berechnung von MD5 oder SHA1 Signaturen der Dateidaten.

• Wiederherstellungs-Funktionen
  • leicht verständliche und erweiterbare Konfigurationsdateien für jeden einzelnen Dämonprozess.

• SQL-Datenbank
  • eine Catalog-Datenbank zur Aufzeichnung der Volumes, Pools, Jobs und der Informationen über die gesicherten Dateien.
  • Unterstützung von SQLite, PostgreSQL und MySQL als Catalog-Datenbanksystemen.
  • vom Benutzer erweiterbare Datenbankabfragen an SQLite-, PostgreSQL und MySQL-Datenbanksysteme.

• fortschrittliches Volume- und Pool-Management
  • gekennzeichnete Volumes, die ein versehentliches überschreiben (zumindest durch Bacula) verhindern.
  • eine beliebige Anzahl verschiedener Jobs und Clients kann auf ein einzelnes Volume gesichert werden. Dies bedeutet, dass von Linux-, Unix-, Sun- und Windows-Rechnern auf das gleiche Volume gesichert werden kann. Das gleiche gilt für die Wiederherstellung.
  • eine Sicherung kann sich über mehrere Volumes erstrecken. Sobald ein Volume voll ist, fordert Bacula automatisch das nächste Volume an und setzt die Sicherung fort.
  • die Verwaltung von Pools und Volumes erlaubt einen flexiblen Umgang mit Volumes (z.B. Gruppen von Volumes für die monatliche, wöchentliche, tägliche Sicherung, Gruppen von Volumes für bestimmte Clients).
  • das Datenformat der Volumes ist systemunabhängig. Bei Bedarf können die Daten von Linux-, Solaris- und Windows-Clients in dasselbe Volumen gespeichert werden.
  • jede Bacula-Version kann jedes, mit einer kleineren Version, erstellte Volume lesen.
  • ein konfigurierbares Messages-Handling. Dazu gehört der Versand von Botschaften aller Dämon-Prozesse an den Director-Dienst und die automatische Benachrichtigung des Benutzers über das Mailsystem.
  • Zwischenspeicherung der zu sichernden Daten auf der Festplatte (Spooling) und fortlaufende Beschreibung des Bandes mit den zwischengespeicherten Daten verhindert den ``Schoe-Shine-Effekt'' bei einer inkrementellen oder differentiellen Sicherung.

• Unterstützung für fast alle Speicher-Geräte
  • die Unterstützung von Autochangern über ein einfache Shell-Schnittstelle. Damit ist es möglich, praktisch mit jedem Autoloader-Programm zu kommunizieren. Ein Skript für mtx ist bereitgestellt.
  • unterstützt Autochanger-Barcodes -- entsprechend der Barcodes wird das Band gekennzeichnet.
  • automatische Unterstützung mehrerer Autochanger-Magazine. Hierbei wird entweder der Barcode oder das Band gelesen.
  • Unterstützung von Autochangern mit mehreren Laufwerken
  • Sicherung/Wiederherstellung als raw-Backup. Hierbei muß die Wiederherstellung auf den gleichen Datenträger erfolgen.
  • jeder Datenblock (etwa 64KByte) der Volumes enthält die Prüfsumme der Daten.
  • Migration, die Möglichkeit gesicherte Daten von einem Pool oder Volume, in einen anderen Pool oder auf ein anderes Volume zu verschieben.
  • schreibbare DVD können als Backup-Medium verwendet werden

• Unterstützung verschiedener Bertiebssysteme
  • Programmtechnisch keine Begrenzung der Länge der Dateinamen oder der Nachrichten. Auf Win32 ist die Länge der Dateinamen/Pfade auf 64k begrenzt.
  • GZIP-Komprimierung für jede einzelne Datei, die schon der Client erledigt, sofern dies vor einer Übertragung im Netzwerk angefordert wird.
  • POSIX ACLs werden - wenn aktiviert - unter den meisten Betriebssystemen gesichert und wiederhergestellt.
  • Zugangskontrolllisten für Consolen, die dem Benutzer einen Zugang nur zu den eigenen Daten erlauben.
  • Sicherung/Wiederherstellung von Dateien, die größer sind als 2GB.
  • Unterstützung von 64Bit-Systemen wie z.B. AMD64.
  • Unterstützung von ANSI- und IBM Band-Labels.
  • Unterstützung von Unicode-Dateinamen (z.B. Chinesisch) auf Win32-Rechnern mit der Bacula-Version 1.37.28 und höher.
  • konsistente Sicherung von geöffneten Dateien von Win32-Systemen (WinXP, Win2003, nicht Win2000) durch Verwendung von Volume Shadow Copy (VSS).

• Verschiedenes
  • Implementierung der Prozesse als Multithread-Programme.
  • leicht verständliche und erweiterbare Konfigurationsdateien für jeden einzelnen Dämonprozess.

Vorteile gegenüber anderen Sicherungsprogrammen

• da für jeden Rechner ein eigener Client existiert, können die Daten von Betriebssystemen aller Art gesichert und wiederhergestellt werden, wobei immer gewährleistet ist, dass ihre Dateiattribute korrekt gesichert und wiederhergestellt werden.
• Man kann auch Clients sichern ohne eine Client-Software zu benutzen und verwendet hierzu NFS oder Samba. Wir empfehlen jedoch, sofern möglich, auf jedem Rechner, von dem Daten gesichert werden sollen, einen eigenen File-Dämon laufen zu lassen.
• Bacula kann mit Sicherungen umgehen, die auf mehrere Volumes verteilt sind.
• eine umfassende SQL-Datenbank aller gesicherter Dateien ermöglicht den Überblick über alle gespeicherte Dateien in jedem einzelnen Volume.
• automatische Bereinigung der Datenbank (die Entfernung alter Aufzeichnungen) und dadurch eine Vereinfachung der Datenbankadministration.
• durch die Verwendung beliebiger SQL-Datenbanksysteme ist Bacula sehr anpassungsfähig. Derzeit werden MySQL, PostgreSQL und SQLite unterstützt.
• durch den modularen, dabei aber einheitlichen Entwurf ist Bacula in hohem Maße skalierbar.
• da Bacula Dämonen auf den Client-Rechnern benutzt, ist es möglich, dort laufende Anwendungen durch Bacula mit systemeigenen Befehlen zu stoppen und nach der Sicherung die entsprechenden Anwendungen wieder zu starten. Dies alles kann aus einem einzigen Bacula-Job heraus geschehen.
• Bacula hat ein eingebauten Zeitplaner für die Sicherungsjobs.
• Das Format der Volumes ist dokumentiert und es gibt einfache C-Programme mit denen sie gelesen und beschrieben werden können
• Bacula benutzt eindeutige (bei der IANA registrierte) TCP/IP-Ports -- also weder RPCs noch Shared Memory.
• Baculas Installation und Konfiguration ist gegenüber anderen vergleichbaren Produkten relativ einfach.
• hohe Geschwindigkeit durch das Speichern der Datei-Informationen in einer SQL-Datenbank anstatt in einzelnen Dateien auf der Festplatte.
• neben der grafischen Benutzeroberfläche zur Verwaltung hat Bacula eine umfassende Shell-Schnittstelle für die Wartungsaufgaben, wobei der Administrator Werkzeuge wie z.B. ``ssh'' verwenden kann, um jeden Teil von Bacula von überall (sogar von Zuhause) zu administrieren.
• Bacula hat eine Rettungs-CD für Linux-Systeme mit den folgenden Eigenschaften:
  • Sie kompilieren sie von Grund auf auf ihrem eigenen System mit einem einzigen einfachen Befehl: ``make'' (...OK, Sie brauchen dann noch ``make burn''...).
  • die Rettungs-CD verwendet Ihren Kernel
  • sie schreibt Skripte entsprechend der Parameter Ihrer Festplatte mit denen Sie diese automatisch repartitionieren und formatieren können, um den Ausgangszustand wieder herzustellen.
  • sie hat ein Skript, das Ihr Netzwerk wieder starten wird (mit der korrekten IP-Adresse)
  • sie hat ein Skript, mit dem Ihre Festplatten automatisch gemountet werden.
  • ein Bacula-Client ist statisch eingebunden
  • sie können der Rettungs-CD auf einfache Weise zusätzliche Daten und Programme hinzufügen.

Einschränkungen der aktuellen Implementierung

• Sollten Sie mehr als 4 Milliarden Dateieinträge in Ihrer Datenbank gespeichert haben, wird die FileID der Datenbank vermutlich überlaufen. Dies wäre eine ziemlich große Datenbank, aber immerhin ist sie denkbar. Allerdings können Sie die FileID auf 64 Bit erweitern (ab Bacula-Version 1.39) und das Problem ist gelöst, dies muss aber von Hand geschehen.
• Dateien, die nach einer Vollsicherung gelöscht wurden, werden bei einer Wiederherstellung eingeschlossen. Es wird momentan daran gearbeitet, dies zu verhindern.
• differentielle und inkrementelle Sicherungen basieren auf den Zeitstempeln der Dateien. Das bedeutet, dass falls Sie nach einen vollständigen Sicherung Verzeichnisse oder Dateien auf dem Client in das FileSet verschieben, diese beim nächsten inkrementellen Backup nicht gesichert werden. Um das Sichern der Daten zu erzwingen, müssen Sie nach dem verschieben die Timestamps der Daten aktualisieren, damit Bacula sie als neu erkennt.
• Datei-System-Module fehlen (dies wären konfigurierbare Routinen, um spezielle Dateien zu sichern/wiederherzustellen, das kann aber über RunScripts gelöst werden).
• Bacula kann zwei verschiedene Jobs nicht im selben Restore wiederherstellen, wenn diese Backup-Jobs gleichzeitig gelaufen sind. Die Ausnahme ist, dass Sie Spooling aktiviert haben und die Jobs nach dem spoolen nacheinander auf das Volume geschrieben wurden. Es ist also nicht möglich, die verschachtelten Blöcke auf dem Volume in einem Job zu trennen.
• generell kann Bacula jedes Backup von jedem Client auch auf einem anderen Client wiederherstellen. Allerdings gibt es, wenn die Architektur der Rechner unterschiedlich ist (z.B. 32Bit zu 64Bit oder Windows zu Unix) einige Einschränkungen. Zum Beispiel kennt Linux/Unix keine Solaris door-Dateien. Zudem gibt es Hinweise, dass sich Zlib-Kompremierte Dateien von 64Bit-Systemen nicht immer korrekt auf 32Bit-Systemen entpacken lassen.

Grenzen und Beschränkungen des Software Design

• Namen (Resource-Namen, Volume-Names und ähnliche) in Baculas Konfigurationsdateien sind auf eine bestimmte Länge beschränkt . Momentan liegt die Grenze bei 127 Zeichen. Beachten Sie bitte, dass diese Einschränkungen nicht die Dateinamen betrifft, die beliebig lang sein können.