Bacula Workshop - Teil 2

Einführung in Bacula - Teil 2und Aufbau eines Testsystems

vorgestellt am 10.09.2010 in Pforzheim

Daniel Bäurer

inovex GmbH

Systems Engineer Linux

Was ich mit Ihnen besprechen möchte

Agenda

1. Offene Punkte vom Vortag

2. Hardwareanforderung

3. Berechnung des benötigten Speicherplatz der Datensicherung

4. Planung der Backupstrategie

5. Aufbau des Testsystems

Einführung in Bacula

26.07.12 2

BaculaEin Open-Source Netzwerk-Backupsystem

26.07.12 3

Offene Punkte vom Vortag


26.07.12 4

Bacula – Offene Punkte vom Vortag: Kompression

● Wenn in den FileSets die Option „Compression = GZIPx“ aktiviert ist, wird die Komprimierung vom File-Daemon ausgeführt.

● Der Kompressionsalgorithmus ist GZIP. Durch die Benutzung von GZIP1 bis GZIP9 kann der Kompressionsgrad eingestellt werden.

● Sofern das Bandlaufwerk über die Funktion „Hardware Compression“ verfügt und diese aktiviert ist, sollte auf die softwareseitige Kompression verzichtet werden.

● Durch die Direktive „Allow Compression = no“ auf dem Storage-Daemon, kann eine softwareseitige Kompression generell abgeschaltet werden.


26.07.12 5

Bacula – Offene Punkte vom Vortag: File-Daemon ohne Root-Rechte

● Der File-Daemon kann ohne Root-Rechte laufen, indem dieser mit den Schaltern -u (user, userid) und -g (group, groupid) gestartet wird.

● Hierzu müssen im Startscript /etc/init.d/bacula-fd der Option ARGS die entsprechenden Schalter übergeben werden.

● Alternativ kann ein Read-only File-Daemon konfiguriert werden.

● Hierzu wird zusätzlich zu den beiden Schaltern -u und -g der Schalter -k übergeben. Dadurch werden dem File-Daemon volle Leserechte aber keine Schreibrechte gewährt.


26.07.12 6

Bacula – Offene Punkte vom Vortag: Logausgaben in syslog

● Die Ausgabe von Logs kann sehr einfach über die Messages-Ressource in verschiedenste Ziele umgeleitet oder dupliziert werden.

● Sobald einer Messages-Ressource der Eintrage „syslog = all, !skipped“ hinzugefügt wird, schreibt Bacula auch in syslog.


26.07.12 7

Bacula – Offene Punkte vom Vortag: Verify als tripwire Ersatz?

● Damit Bacula ein Verify ausführen kann, müssen Initial die Datei-Informationen in den Bacula-Catalog übertragen werden.

● Hierzu muss für jeden Client (der kontrolliert werden soll), einmalig oder nach jeder Änderung, ein Job mit Level = InitCatalog ausgeführt werden.

● Hiernach kann ein täglicher Job zeitgesteuert ausgeführt werden, der die Datei-Informationen mit denen im Katalog abgleicht. Dies wird durch den Level = Catalog erreicht.

● Als Signatur kann SHA1 oder MD5 verwendet werden. Diese, sowie weitere Kriterien, werden über die FileSet-Ressource eingerichtet.


26.07.12 8

Bacula – Offene Punkte vom Vortag: Auto-Restore Ort-1 => Ort-2

● Dies ist leider nicht möglich.

● Ein Restore kann nur über das Konsolen-Kommando „restore“ ausgeführt werden.

● ABER: Es ist möglich die bconsole (Bacula-Console) mit Befehlen zu „füttern“

./bconsole -c ./bconsole.conf <<END_OF_DATA

restore current all

yes

quit

END_OF_DATA


26.07.12 9

Hardwareanforderung


26.07.12 10

Bacula – Hardwareanforderungen

● Der Katalog benötigt mit die meisten Ressourcen, was CPU und Speicher angeht.

● Die größten verzeichneten Systeme im Bacula-Wiki (über 500 Mio. Zeilen in der File-Table) haben mindestens 6 GB RAM und verfügen über mindestens 4 Kern-CPUs.

● Die Größe des Katalog ist sehr stark davon abhängig wie lange Datei-Informationen vorgehalten werden.

● Bei der abzusehenden Größe des Backupsystems, sollten mindestens 8GB RAM und eine 4-Kern-CPU verbaut werden.


26.07.12 11

Bacula – Hardwareanforderungen

● Der Festplattencontroller sollte den zu erwartenden Durchsatz bewältigen können.

● Anschlüsse für externe SCSI-Bandlaufwerke sollten ebenfalls bedacht werden.

● Eventuell kann es sinnvoll sein ein separates Backendnetz zur Datensicherung zu verwenden.


26.07.12 12

Berechnung des benötigten Speicherplatz für die

Datensicherung


26.07.12 13

Bacula – Berechnung des benötigten Speicherplatz: Ein Beispiel

● Ein Vollbackup aller Daten hat die Größe von 20GB.

● Wenn jeden Monat ein Vollbackup erzeugt wird und die Vorhaltezeit 1 Jahr beträgt, liegt der Speicherbedarf bei 12*20GB = 240GB

● Aufbauend auf dem monatliche Vollbackup soll jede Woche ein differentielles Backup erzeugt werden. Die Datenmenge die sich wöchentlich ändert liegt bei 4GB. Daraus ergibt sich ein Speicherbedarf von 5*4GB = 20GB

● Schließlich wird jeden Tag noch ein inkrementelles Backup erzeugt. Daraus ergibt sich ein Speicherbedarf von 7*0,6GB = 4,2GB


26.07.12 14

Bacula – Berechnung des benötigten Speicherplatz: Ein Beispiel

● Vollbackup MySQL-Dump, 60GB pro Tag, 30 Tage Vorhaltezeit:

30*60GB = 1800GB

● Vollbackup restliche Daten, 40GB pro Woche, 3 Monate Vorhaltezeit:

15*40GB = 600GB

● Inkrementelles Backup restliche Daten, 1GB pro Tag, 7 Tage Vorhaltezeit: 7*1GB = 7GB

● Bandlaufwerk, 2,4TB pro Monat, 12 Monate Vorhaltezeit: 12*2,4TB = 28,8TB (LTO-4 = 36 Bänder oder LTO-5 = 20 Bänder unkomprimiert)


26.07.12 15

Planung der Backupstrategie


26.07.12 16

Bacula – Planung der Backupstrategie: Vorgaben, Wünsche

● Ein Vollbackup soll von folgenden Systemen erzeugt werden: Puppet MySQL-Server Gespeicherte Session-Informationen Weitere Teilbereiche

● Es wird kein Vollbackup von einem gesamten Rechner erzeugt.

● Zwei Speicherorte: Frankfurt (B2D) und Karlsruhe (B2D, später auch D2D2T)

● Bandsicherung soll als Archiv dienen.


26.07.12 17

Bacula – Planung der Backupstrategie: Periphere Einflüsse

● Existieren gesetzliche Bestimmungen in dem zu sicherndem Umfeld?

● Wenn ja, entspricht die Sicherung auf Festplatte den Anforderungen?

● Vorgaben der strategischen und/oder operativen Geschäftsleitung?

● Vorgaben von Kundenseite?

● Zeiträume in denen geringe Lasten vorherrschen?

● Budget?


26.07.12 18

Bacula – Planung der Backupstrategie: notwendige Informationen

● Zu sicherndes Datenvolumen (unterteilt der einzelnen Bereiche)

● Änderungsvolumen (pro Tag, Woche, Monat)

● Wachstum des Datenvolumens (pro Woche, Monat, Jahr)

● Vorhaltezeit auf dem B2D-Storage in Frankfurt

● Vorhaltezeit auf dem B2D-Storage in Karlsruhe

● Vorhaltezeit im Archiv (Bänder)


26.07.12 19

Bacula – Beschreibung eines möglichen Szenarios

● MySQL-Dumps werden einmal (oder mehrmals?) täglich erstellt und gesichert. Da sich die Dumps zu jedem Zeitpunkt unterscheiden, wird de facto täglich ein Vollbackup erstellt.

● Für die restlichen Bereiche könnte wöchentlich (für manche Teilbereiche mit geringem Datenaufkommen monatlich) ein Voll- und täglich ein inkrementelles-Backup erstellt werden.

● Die Vorhaltezeit am Speicherort in Frankfurt könnte 1-3 Monate betragen. In Karlsruhe könnte sie, da es nur ein Worst-Case-System ist, bei 1 Monat liegen.

● Am Ende des Monats würde die Archivierung auf Band erfolgen.


26.07.12 20

Bacula – Überlegungen zur Konfiguration von Bacula

● Für die MySQL-Dumps würde sich ein eigenständiger Pool anbieten. Grund: Geringere Vorhaltezeiten für MySQL-Dumps möglich.

● Für die restlichen Bereiche könnten zwei Pools verwendet werden.

Grund: Auch hier die unterschiedlichen Vorhaltezeiten.

● Für den Storage in Kalrsruhe genügt ein Pool, da sich die Vorhaltezeit nicht unterscheidet.

● Für das Archiv auf Band würde wiederum ein Pool genügen.


26.07.12 21

Bacula – Überlegungen zur Konfiguration von Bacula

● Die Sicherung würde täglich auf beide Storge-Systeme in Frankfurt und Karlsruhe erfolgen.

● Gesteuert wird alles aus dem RZ in Frankfurt (auch sämtliche Komponenten in Karlsruhe).


26.07.12 22

Aufbau des Testsystems

inovex GmbH

PforzheimKarlsruher Straße 71D-75179 Pforzheim

MünchenKonrad-Zuse-Platz 1D-81829 München

KölnHansaring 68-70D-50670 Köln

Vielen Dank für Ihre Aufmerksamkeit!

Technology

Bacula Workshop - Teil 2