Einführung in Bacula Teil 1 und Aufbau eines Testsystems

Transkript

1 Einführung in Bacula Teil 1 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. Begrüßung 2. Was ist Bacula? 3. Merkmale von Bacula 4. Aufbau von Bacula (Komponenten) 5. Aufbau der Konfiguration (Ressourcen) 6. Grundkonfiguration des Bacula-Backupsystems

3 Was ich mit Ihnen besprechen möchte Einführung in Bacula Agenda 7. Erweiterte Konfiguration des Bacula-Backupsystems 8. Backup von MySQL-Datenbanken 9. Backup-to-Disk (B2D) mit Bacula 10. Disk-to-Disk-to-Tape (D2D2T) mit Bacula 11. Integration einer Tape-Library 12.Offener Themenbereich

4 Was ist Bacula?

5 Bacula Netzwerkfähiges Open-Source Datensicherungsprogramm Quelltext weitestgehend unter der GPL V2 Modulares Architekturmodell (Kapselung der Aufgaben) Wird entwickelt für Linux, BSD, Unix, Mac OS X und Windows

6 Bacula Historie Bacula bedeutet BACkup und DracULA Projektstart im Januar 2000 durch Kern Sibbald Erste Version wurde im April 2002 veröffentlicht Aktuelle Version ist 5.0.3, erschienen im August 2010 (Ubuntu LTS: 5.0.1, Debian 6.0: 5.0.2)

7 Bacula Urspüngliche Zielsetzung Sichert alles vom Palm bis zur Mainframe Bietet vergleichbare Funktionen wie kommerzielle Produkte Kompatibilität für die nächsten 30 Jahre Skalierbar (mehr als Systeme)

8 Merkmale von Bacula

9 Bacula Merkmale Automatisches, zeitgleiches und priorisiertes Sichern von Systemen Sichert auf verschiedenste Medien (Band, Festplatte, CD/DVD, USB) Kann mit den meisten Bandlaufwerken und Tape-Libraries umgehen Unterstützt Barcode-Geräte Backup über mehrere Medien und mehrere Backups auf ein Medium

10 Bacula Merkmale Sehr schnelles und interaktives Wiederherstellen der Daten Ausführen von Skripten vor und nach einem Backup oder Fehler Schutz vor Überschreiben von Medien Signatur für jede Datei und Prüfsumme der Sicherung Verschlüsselung der Kommunikation und der Daten

11 Bacula Modulares Konzept Client-Server-Modell Kapselung der Aufgaben in Modulen (Komponenten) Sehr hohe Skalierbarkeit der Komponenten Interaktion der Komponenten über TCP/IP Gegenseitige Authentifizierung der Komponenten

12 Aufbau von Bacula (Komponenten)

13 Bacula Interaktion der Komponenten Aus Aus

14 Bacula Komponenten Director (bacula-dir) Oberste Instanz des Backup-Systems Koordiniert sämtliche Komponenten Steuert Backups und die Wiederherstellung In typischen Szenarien nur einmal vorhanden Läuft als Daemon (ohne root-rechte möglich)

15 Bacula Komponenten Catalog (SQL-DB) Gedächtnis des Backup-Systems Speichert die Metadaten (Dateiindex, Attribute, etc.) Verwaltung der Sicherungsmedien Kann zur Erstellung von Berichten genutzt werden Unterstützt werden MySQL, PostgreSQL oder SQLite

16 Bacula Komponenten Storage-Daemon (bacula-sd) Kapselt den physischen Zugriff auf die Sicherungsmedien Archivierung auf unterschiedliche Medien (HDD, Band, USB) Pro Storage mehrere und unterschiedliche Medien möglich Mehrere Storage pro Backup-System möglich Läuft als Daemon (ohne root-rechte möglich)

17 Bacula Komponenten File-Daemon (bacula-fd) Läuft auf allen Rechnern die gesichert werden sollen Führt das Backup nach Anweisung des Bacula-Director aus Ebenso wie die Wiederherstellung und den Datei-Abgleich Kommuniziert sowohl mit dem Director als auch dem Storage Benötigt vollen Zugriff auf das System (root-rechte notwendig)

18 Bacula Komponenten Console (CLI, GUI, Web-GUI) Administrations- und Benutzerschnittstelle zum Bacula-Director Manuelle Einflussnahme auf das Backup-System Unterschiedlichste Restriktionen möglich Monitor (GUI) Status-Schnittstelle Zustandsanzeige für alle Komponenten

19 Aufbau der Konfiguration (Ressourcen)

20 Bacula Ressourcen Aus

21 Bacula Ressourcen Ressourcen (Objekte) abstrahieren das Backup-System Ressourcen enthalten mehrere Direktiven Ressourcen können weitere Ressourcen einbinden Eine Komponente wird aus mehreren Ressourcen gebildet Die Benamung der Ressourcen muss eindeutig sein

22 Bacula Ressourcen Pool-Ressource Wird vom Bacula-Director verwendet Besteht aus der Ressource Volume Gruppiert Volumes Sicherung ist auf die Größe des Pools beschränkt Meta-Daten (Volumes, usw.) werden im Katalog vorgehalten

23 Bacula Ressourcen Volume-Ressource Wird verwendet durch die Ressource Pool Sicherungsmedium (physikalisches Band, einzelne Datei) Meta-Daten (Anzahl Mounts, usw.) werden im Katalog vorgehalten Digitale Kennzeichnung (label) fügt Volume einem Pool hinzu

24 Bacula Ressourcen Job-Ressource Wird verwendet durch den Bacula-Director Beschreibt genau eine Aufgabe die Bacula ausführen soll Besteht aus den Ressourcen Pool, FileSet, Schedule, Storage und Client Aufgaben können vom Typ Backup, Restore, Verify oder Admin sein

25 Bacula Ressourcen FileSet-Ressource Gibt Dateien/Verzeichnisse an die zu sichern sind (include und exclude) Definiert wie zu sichern ist (komprimiert, signiert, usw.) Schedule Zeitplan, der beschreibt wann Aktionen ausgeführt werden Bindet die Job-Ressource kein Zeitplan ein, so kann der Job nur manuell ausgeführt werden

26 Bacula Ressourcen Storage-Ressource Bestimmt mit welcher Komponente gesichert werden soll Ist ein Verweis auf die zu verwendende Storage-Komponente Client-Ressource Bestimmt welcher Rechner sichern soll Ist ein Verweis auf die zu verwendende File-Komponente JobDefs-Ressource Fasst allgemeingültige Definitionen für Jobs zusammen

27 Bacula Komponentenspezifische Ressourcen Director-, Client- und Storage-Ressource Konfiguration der Komponenten Benutzungsrechte der Komponente Device-Ressource Konfiguration des Sicherungs-Mediums Messages Konfiguration der Benachrichtigungen

28 Grundkonfiguration des Bacula-Backupsystems

29 Bacula Grundkonfiguration des Backupsystems Die Grundkonfiguration des Backupsystems erfolgt anhand der Ressourcen einer Komponente. Für ein grundlegendes Bacula-System werden folgende Komponenten benötigt: Director mit Catalog Steuerung des Systems Console Beeinflussung des Systems Storage-Daemon Speicherort der Sicherungsdaten File-Daemon Sichern des Bacula-Director und -Catalog Alle Komponenten können auf der selben Hardware residieren

30 Bacula Grundkonfiguration des Backupsystems Die Konfigurationsdateien der Komponenten befinden sich unterhalb von /etc/bacula in bacula-dir.conf Director, Catalog und weitere Ressourcen bconsole.conf Console bacula-sd.conf Storage-Daemon bacula-fd.conf File-Daemon Die Konfiguration einer Ressource beginnt immer mit einer Deklaration des Ressourcen-Typs

31 Bacula Konfiguration des Director und Catalog Der Bacula-Director wird über die Ressource Director deklariert. Das Passwort wird zur Anmeldung durch die Console benötigt. Director { Name = baculademo-dir Description = "Dies ist der baculademo Backup-Server auf Basis von Bacula DirAddress = Dirport = 9101 password = "IrgendwasNettes" Messages = Daemon WorkingDirectory = "/var/lib/bacula" PidDirectory = "/var/run/bacula" QueryFile = "/etc/bacula/scripts/query.sql" Maximum Concurrent Jobs = 1 }

32 Bacula Konfiguration des Director und Catalog Ebenfalls in der bacula-dir.conf wird der zu verwendende Bacula- Catalog deklariert (mehrere Kataloge möglich). Initial angelegt wird der Bacula-Catalog anhand vorgefertiger SQL- Scripte auf einem entsprechenden SQL-Dienstserver. Catalog { Name = baculademo-cat DB Name = bacula DB Address = DB Port = 3306 user = bacula password = "AuchwasNettes" }

33 Bacula Konfiguration von Pools Pools werden über die Ressource Pool deklariert. Volumes werden einem Pool über die Bacula-Console und dem Kommando label zugeordnet. Pool { Name = File-Dayly-Pool Pool Type = Backup Storage = File-Storage Volume Retention = 10 days Maximum Volume Bytes = 650MB AutoPrune = yes Recycle = yes LabelFormat = File-Dayly-Volume Next Pool = Off-Site-Pool }

34 Bacula Konfiguration von Clients Eine Client-Ressource stellt einen Verweis auf den zu sichernden Rechner dar, auf dem ein erreichbarer File-Daemon läuft. Das Passwort wird zur Anmeldung am File-Daemon benötigt. Client { Name = bacula-client-1.localdomain Address = FDPort = 9102 Catalog = baculademo-cat Password = "WiederumwasNettes" File Retention = 7 days Job Retention = 14 days AutoPrune = yes }

35 Bacula Konfiguration von Storages Eine Storage-Ressource ist ein Verweis auf den Storage-Daemon, auf dem die zu sichernden Daten geschrieben werden. Das Passwort wird zur Anmeldung am Storage-Daemon benötigt. Storage { Name = File-Storage Address = SDPort = 9103 Password = "ErneutwasNettes" Device = FileStorage Media Type = File }

36 Bacula Konfiguration von FileSets FileSets können anhand von includes und excludes erstellt werden. Wildcards und RegEx sind möglich. FileSet { Name = Full-File-Set Include { File = / Options { signature = MD5; hardlinks=yes } } Exclude { File = /var/lib/mysql }

37 Bacula Konfiguration von Schedules Die Schedule-Ressource beinhaltet einen oder mehrere Zeitpläne für die Sicherung. Ebenfalls können Konfigurationen bestimmter Ressourcen (Jobs) überschrieben werden. Schedule { Name = Weekly-Backup-Schedule Run = Level=Full sat at 23:05 Run = Level=Differential sun-fri at 23:05 }

38 Bacula Konfiguration von Jobs und JobDefs Sämtliche Parameter einer Job-Ressource können in die JobDefs- Ressource ausgelagert werden. Eine Job-Ressource kann Einstellungen der JobDefs-Ressource überschreiben. Job { Name = baculademo.localdomain-mysqlbackup Client = baculademo.localdomain JobDefs = Default-Job Level = Full Schedule = Catalog-Backup-Schedule Priority = 11 Run Before Job = "/etc/bacula/scripts/make_catalog_backup.pl baculademo-cat" RunAfterJob = "/etc/bacula/scripts/delete_catalog_backup" }

39 Bacula Konfiguration des Storage-Daemon Ein Storage-Daemon wird über die Ressource Storage deklariert. Die IP-Adresse und der Port muss sowohl für den Bacula-Director als auch die File-Daemons, die den Storage zum sichern benutzen, erreichbar sein. Storage { Name = baculademo-sd SDAddress = SDPort = 9103 WorkingDirectory = "/var/lib/bacula" PidDirectory = "/var/run/bacula" Maximum Concurrent Jobs = 20 }

40 Bacula Konfiguration des Storage-Daemon Damit der Bacula-Director den Storage-Daemon verwenden kann, wird dieser über die Ressource Director bekannt gemacht. Das Passwort benötigt der Bacula-Director um sich am Storage- Daemon anzumelden. Ein Storage-Daemon kann von mehreren Director-Instanzen verwendet werden. Director { Name = baculademo-dir Password = "ErneutwasNettes" Monitor = no }

41 Bacula Konfiguration des Storage-Daemon Der Storage-Daemon steuert das Gerät an, auf dem die Daten gesichert werden sollen. Dieses muss ebenfalls deklariert werden (Ressource Device). Device { Name = FileStorage Archive Device = /backup Device Type = File Media Type = File Random Access = yes Maximum Volume Size = 20GB Maximum File Size = 650MB LabelMedia = yes }

42 Bacula Konfiguration des File-Daemon Ein File-Daemon wird über die Ressource FileDaemon deklariert. Die IP-Adresse und der Port müssen für den Bacula-Director erreichbar sein. FileDaemon { Name = baculademo-fd FDAddress = FDport = 9102 WorkingDirectory = "/var/lib/bacula" PidDirectory = "/var/run/bacula" Maximum Concurrent Jobs = 20 }

43 Bacula Konfiguration des File-Daemon Auch dem File-Daemon muss, wie dem Storage-Daemon, der Director bekannt gemacht werden, der sich mit ihm verbinden darf. Das Passwort benötigt ebenfalls der Bacula-Director um sich am File-Daemon anmelden zu können. Auch ein File-Daemon kann von mehreren Directoren angesprochen werden. Director { Name = baculademo-dir Password = "WiederumwasNettes" Monitor = no }

44 Erweiterte Konfiguration des Bacula-Backupsystem

45 Bacula Erweiterte Konfiguration: Run Command und RunScript Mit Run Command können vor oder nach einem Job, aber auch in einem Fehlerfall, Kommandos ausgeführt werden. Mit Run Script können komplexere Strukturen abgebildet werden. RunScript { RunsWhen = Before FailJobOnError = No Command = "/etc/init.d/apache stop" } RunScript { RunsWhen = After RunsOnFailure = yes Command = "/etc/init.d/apache start" }

46 Bacula Erweiterte Konfiguration: Unterstützung von TLS Die Kommunikation zwischen den Komponenten kann mit TLS verschlüsselt werden. TLS kann aktiviert sein, muss allerdings nicht zwingend von den Komponenten verwendet werden. Selbstsignierte Zertifikate sind nur mit Einschränkung nutzbar. Es ist besser wenn man eine eigene oder offizielle CA verwendet. TLS Enable = yes TLS Require = no TLS Certificate = /etc/ssl/private/bacula.pem TLS Key = /etc/ssl/private/bacula.pem TLS CA Certificate File = /etc/ssl/private/ca.pem

47 Bacula Erweiterte Konfiguration: Unterstützung von PEK Die zu sichernden Daten können mit Private/Public Encryption Keys verschlüsselt und signiert werden. Um eine Wiederherstellung nicht zu gefährden, sollte zumindest der Masterkey an einem sicheren Ort gelagert werden! Die Verschlüsselung wird auf/von jedem File-Daemon durchgeführt. PKI Signatures = Yes PKI Encryption = Yes PKI Keypair = /etc/ssl/private/bacula.pem PKI Master Key = /etc/ssl/private/master.cert

48 Backup von MySQL- Datenbanken

49 Bacula Backup von MySQL-Datenbanken Bacula liefert keinerlei Schnittstellen für das (Online-) Backup von MySQL-Datenbanken. In Verbindung mit Run Command oder RunScript können die MySQL-Werkzeugen wie mysqldump oder mysqlhotcopy verwendet werden. Einschränkungen in Bezug auf die verwendete Storage-Engine (InnoDB, MyISAM, NDB) und Schreibschutz (LOCK TABLE) Verwendung etablierter Sicherungsmethoden für MySQL mit Bacula (Master-Slave, NDB-Backup, Binary-Log, LVM-Snapshot, etc.)

50 Bacula MySQL-Backup mit mysqldump mysqldump eignet sich sowohl für die MyISAM- als auch InnoDB- Storage-Engine. Für Datenbank-Server mit gemischten Storage-Engines gut geeignet. Bei großen Datenbanken wird durch das Erzeugen des Dumps eine sehr große Last erzeugt. Wenn der Dump ohne Locks erzeugt wird, könnte ein inkonsistenter Zustand der Daten erzeugt werden

51 Bacula MySQL-Backup mit mysqlhotcopy mysqlhotcopy eignet sich nur für die MyISAM-Storage-Engine. Für diesen Typ ist es aber der Sicherung mit mysqldump vorzuziehen. Bei großen Datenbanken, im Vergleich zu mysqldump, sehr schnell. Das Sicherungsvolumen ist wesentlich höher als bei mysqldump. mysqlhotcopy verwendet LOCKING was zwar konsistente Sicherungen erzeugt aber nicht für alle Datenbanken in Frage kommt

52 Bacula MySQL-Backup mit mysqldump und mysqlhotcopy Bacula kann ein MySQL-Backup mit den beiden Werkzeugen sehr einfach durch die Option Client Run Before Job ausführen. Dabei wird ein (typisches) Script auf dem Client (MySQL-Server) hinterlegt, dass vor dem eigentlichen Backup-Job ausgeführt wird. Anschließend speichert Bacula die MySQL-Sicherung Mit Client Run After Job kann die erzeugte Sicherungen abschließend auf dem Client gelöscht werden. Client Run Before Job = "/etc/bacula/scripts/make_dump.sh" Client Run After Job = "/etc/bacula/scripts/delete_dump.sh"

53 Bacula MySQL-Backup mittels Master-Slave-Replikation Um einige Nachteile (Locking, Last, etc.) der beiden MySQL- Werkzeuge mysqldump und mysqlhotcopy zu umgehen, kann man auf eine Master-Slave-Replikation zurückgreifen. Dabei werden alle Sicherungsaufgaben der beiden Werkzeuge auf dem Slave durchgeführt. Als Alternative zu den beiden Werkzeugen, kann der Slave in einen konsistenten Zustand gebracht ( stop slave ) und MySQL angehalten werden. Anschließend wird das gesamte MySQL-Data-Verzeichnis mittels RunScript oder Run Command gesichert

54 Bacula Weitere MySQL-Backup-Methoden Um ein MySQL-Cluster zu sichern, kann auf die implementierte Backup-Funktion der NDB-Cluster-Engine zurückgegriffen werden. Nachdem die Sicherung erzeugt wurde, können die Metadaten (.ctl), die Tabellendatensätze (.data) und die Transaktionslogs (.log) von jedem Cluster-Knoten gesichert werden. Erstellen und Sichern von MySQL-Binlog-Dateien Verwendung von InnoDB Hot Backup (kommerziell) oder das erzeugen eines LVM-Snapshot

55 Backup-to-Disk (B2D) mit Bacula

56 Bacula Backup-to-Disk (B2D) Auf dem Storage-Daemon wird die Sicherung in Dateien in einer eigenen Ressource (Device) deklariert. Als Sicherungsziel (Archive Device) wird einfach ein Verzeichnispfad sowie als Medientyp File angegeben. Wenn mehrere B2D-Verzeichnispfade (auf dem selben Storage- Daemon) benutzt werden sollen, muss sich der Medientyp unterscheiden (File1, File2, Filen). Vorteile von B2D sind kürzere Sicherungszeiten, ein schnelleres Wiederherstellen und bieten einen geringeren Sicherungsaufwand

57 Bacula Data-Spooling Data-Spooling schreibt die Daten der Clients zuerst in eine Datei um diese anschließend in einem Vorgang auf Bänder zu schreiben. Dadurch wird verhindert, dass das Bandlaufwerk permanent stoppt und wieder anläuft. Der Sicherungsvorgang wird beschleunigt. Die Spooling-Daten können nicht für eine Wiederherstellung verwendet werden. SpoolData = yes Maximum Spool Size = 400GB Spool Directory = /tmp

58 Disk-to-Disk-to-Tape (D2D2T) mit Bacula

59 Bacula Disk-to-Disk-to-Tape (D2D2T) Bacula bietet die Möglichkeit, Jobs oder Volumes (und weiterer Kriterien) zu migrieren oder kopieren. Dies bildet die Grundlage von D2D2T. Bei der Migration werden die Daten anhand der festgelegten Kriterien von einem Volume auf ein anderes Volume verschoben. Alle Einträge im Bacula-Catalog werden auf das neue Volume umgeschrieben. Beim Kopieren werden die Daten auf ein weiteres Volume dupliziert. Auch die Einträge im Bacula-Catalog werden dupliziert und mit dem Vermerk Copy markiert

60 Bacula Disk-to-Disk-to-Tape (D2D2T) Damit D2D2T benutzt werden kann, muss der entsprechende Pool zwingend die Option Next Pool enthalten. Next Pool bestimmt in welchen Pool Volumes verschoben oder kopiert werden. Eine D2D2T-Job wird wie jeder andere Job angelegt. Allerdings wird der Job-Typ auf Migrate oder Copy gesetzt. Job { Name = "migrate" Type = Migrate Selection Type = Volume Selection Pattern = "File" }

61 Bacula Virtuelles Backup Eine etwas abgewandelte Möglichkeit von D2D2T ist das virtuelle Backup (Vbackup) oder auch Consolidation. Beim Vbackup wird aus dem letzten Vollbackup und den folgenden differentiellen und/oder inkrementellen Sicherungen ein neues Vollbackup erstellt. Als Voraussetzung von Vbackup muss der betreffende Pool ebenfalls über die Option Next Pool verfügen. Ein Vbackup wird dadurch erstellt, indem das Sicherungslevel auf VirtualFull eingestellt wird (Job- oder Schedule-Ressource)

62 Integration einer Tape-Library

63 Bacula Integration einer Tape-Library Bei der Integration von Tape-Libraries greift Bacula auf das MTX- Projekt (Media Changer Tools) zurück. Sämtliche von MTX unterstützen Autochanger (Tape-Libraries) können für Bacula verwendet werden. Bacula liefert ein eigens mtx-script mit, dass die Schnittstelle zu MTX übernimmt (die MTX-Tools steuern den Autochanger). Es können auch Autochanger verwendet werden, die mehr als ein Laufwerk ansteuern

64 Bacula Integration einer Tape-Library Voraussetzung für den Einsatz einer Tape-Library ist, dass Volumes im Katalog existieren (gelabelt sind) und auch einer Slotnummer im Autochanger zugeteilt wurden. Hierfür muss die Storage-Ressource des Bacula-Director angepasst werden. Die Ressource muss den Eintrag Autochanger = yes enthalten. Auch die Device-Ressource des Storage-Daemon muss den Eintag Autochanger = yes enthalten, damit die Tape-Library benutzt werden kann

65 Bacula Integration einer Tape-Libraray Eine typische Konfiguration der Libraray könnte wie folgt aussehen: Autochanger { Name = Autochanger Device = Tape1, Tape2 Changer Device = /dev/sg0 Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" } Device { Name = Tape1 Drive Index = 0 Autochanger = yes Device { Name = Tape2 Drive Index = 1 Autochanger = yes

66 Offener Themenbereich

67 Bacula Offener Themenbereich Planung der Backupstrategie Berechnung des benötigten Speicherplatz für die Datensicherung Hardwareanforderung

68 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