Bacula Workshop - Teil 2

1,075 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,075
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Bacula Workshop - Teil 2

  1. 1. Einführung in Bacula - Teil 2und Aufbau eines Testsystems vorgestellt am 10.09.2010 in Pforzheim Daniel Bäurer inovex GmbH Systems Engineer Linux
  2. 2. Was ich mit Ihnen besprechen möchteEinführung in BaculaAgenda1. Offene Punkte vom Vortag2. Hardwareanforderung3. Berechnung des benötigten Speicherplatz der Datensicherung4. Planung der Backupstrategie5. Aufbau des Testsystems26.07.12 2
  3. 3. BaculaEin Open-Source Netzwerk-Backupsystem Offene Punkte vom Vortag26.07.12 3
  4. 4. BaculaEin Open-Source Netzwerk-BackupsystemBacula – 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 4
  5. 5. BaculaEin Open-Source Netzwerk-BackupsystemBacula – 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 5
  6. 6. BaculaEin Open-Source Netzwerk-BackupsystemBacula – 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 6
  7. 7. BaculaEin Open-Source Netzwerk-BackupsystemBacula – 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 7
  8. 8. BaculaEin Open-Source Netzwerk-BackupsystemBacula – 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_DATA26.07.12 8
  9. 9. BaculaEin Open-Source Netzwerk-Backupsystem Hardwareanforderung26.07.12 9
  10. 10. BaculaEin Open-Source Netzwerk-BackupsystemBacula – 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 10
  11. 11. BaculaEin Open-Source Netzwerk-BackupsystemBacula – 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 11
  12. 12. BaculaEin Open-Source Netzwerk-Backupsystem Berechnung des benötigten Speicherplatz für die Datensicherung26.07.12 12
  13. 13. BaculaEin Open-Source Netzwerk-BackupsystemBacula – 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,2GB26.07.12 13
  14. 14. BaculaEin Open-Source Netzwerk-BackupsystemBacula – 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 14
  15. 15. BaculaEin Open-Source Netzwerk-Backupsystem Planung der Backupstrategie26.07.12 15
  16. 16. BaculaEin Open-Source Netzwerk-BackupsystemBacula – 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 16
  17. 17. BaculaEin Open-Source Netzwerk-BackupsystemBacula – 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 17
  18. 18. BaculaEin Open-Source Netzwerk-BackupsystemBacula – 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 18
  19. 19. BaculaEin Open-Source Netzwerk-BackupsystemBacula – 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 19
  20. 20. BaculaEin Open-Source Netzwerk-BackupsystemBacula – Ü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 20
  21. 21. BaculaEin Open-Source Netzwerk-BackupsystemBacula – Ü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 21
  22. 22. BaculaEin Open-Source Netzwerk-Backupsystem Aufbau des Testsystems26.07.12 22
  23. 23. Vielen Dank für Ihre Aufmerksamkeit!inovex GmbHPforzheim München KölnKarlsruher Straße 71 Konrad-Zuse-Platz 1 Hansaring 68-70D-75179 Pforzheim D-81829 München D-50670 Köln

×