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

Transkript

1 Einführung in Bacula - Teil 2 und Aufbau eines Testsystems vorgestellt am in Pforzheim Daniel Bäurer inovex GmbH Systems Engineer Linux

2 Was ich mit Ihnen besprechen möchte Einführung in Bacula Agenda 1. Offene Punkte vom Vortag 2. Hardwareanforderung 3. Berechnung des benötigten Speicherplatz der Datensicherung 4. Planung der Backupstrategie 5. Aufbau des Testsystems

3 Offene Punkte vom Vortag

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

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

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

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

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

9 Hardwareanforderung

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

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

12 Berechnung des benötigten Speicherplatz für die Datensicherung

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

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)

15 Planung der Backupstrategie

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

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?

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)

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

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

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)

22 Aufbau des Testsystems

23 Vielen Dank für Ihre Aufmerksamkeit! inovex GmbH Pforzheim Karlsruher Straße 71 D Pforzheim München Konrad-Zuse-Platz 1 D München Köln Hansaring D Köln