Bacula Workshop - Teil 1

Einführung in Bacula – Teil 1und Aufbau eines Testsystems

vorgestellt am 09.09.2010 in Pforzheim

Daniel Bäurer

inovex GmbH

Systems Engineer Linux

Was ich mit Ihnen besprechen möchte

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

Einführung in Bacula

26.07.12 2

Was ich mit Ihnen besprechen möchte

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

Einführung in Bacula

26.07.12 3

BaculaEin Open-Source Netzwerk-Backupsystem

26.07.12 4

Was ist Bacula?


26.07.12 5

Bacula – Ein Open-Source Netzwerk-Backupsystem

● 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


26.07.12 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 10.04 LTS: 5.0.1, Debian 6.0: 5.0.2)


26.07.12 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 10.000 Systeme)


26.07.12 8

Merkmale von Bacula


26.07.12 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


26.07.12 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


26.07.12 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


26.07.12 12

Aufbau von Bacula (Komponenten)


26.07.12 13

Bacula – Interaktion der Komponenten

Aus http://www.bacula.org/de/rel-manual/Was_ist_Bacula.html



26.07.12 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)


26.07.12 15


● 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


26.07.12 16


● 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)


26.07.12 17


● 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)


26.07.12 18


● 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


26.07.12 19

Aufbau der Konfiguration (Ressourcen)


26.07.12 20

Bacula – Ressourcen



26.07.12 21


● 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


26.07.12 22


● 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


26.07.12 23


● 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


26.07.12 24


● 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


26.07.12 25


● 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.07.12 26


● 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


26.07.12 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


26.07.12 28

Grundkonfiguration des Bacula-Backupsystems


26.07.12 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.


26.07.12 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.


26.07.12 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 5.0.2“

DirAddress = 192.168.92.10

Dirport = 9101

password = "IrgendwasNettes"

Messages = Daemon

WorkingDirectory = "/var/lib/bacula"

PidDirectory = "/var/run/bacula"

QueryFile = "/etc/bacula/scripts/query.sql"

Maximum Concurrent Jobs = 1

}


26.07.12 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 = 127.0.0.1

DB Port = 3306

user = bacula

password = "AuchwasNettes"

}


26.07.12 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

}


26.07.12 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 = 192.168.92.20

FDPort = 9102

Catalog = baculademo-cat

Password = "WiederumwasNettes"

File Retention = 7 days

Job Retention = 14 days

AutoPrune = yes

}


26.07.12 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 = 192.168.92.10

SDPort = 9103

Password = "ErneutwasNettes"

Device = FileStorage

Media Type = File

}


26.07.12 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

}


26.07.12 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

}


26.07.12 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"

}


26.07.12 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 = 192.168.92.10

SDPort = 9103




}


26.07.12 40


● 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 {


Password = "ErneutwasNettes"

Monitor = no

}


26.07.12 41


● 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

}


26.07.12 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 = 192.168.92.10

FDport = 9102




}


26.07.12 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 {


Password = "WiederumwasNettes"

Monitor = no

}


26.07.12 44

Erweiterte Konfiguration des Bacula-Backupsystem


26.07.12 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"

}


26.07.12 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


26.07.12 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


26.07.12 48

Backup von MySQL-Datenbanken


26.07.12 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.)


26.07.12 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.


26.07.12 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.


26.07.12 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"


26.07.12 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.


26.07.12 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.


26.07.12 55

Backup-to-Disk (B2D) mit Bacula


26.07.12 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.


26.07.12 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


26.07.12 58

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


26.07.12 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.


26.07.12 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"

}


26.07.12 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).


26.07.12 62

Integration einer Tape-Library


26.07.12 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.


26.07.12 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.


26.07.12 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

...


26.07.12 66

Offener Themenbereich


26.07.12 67

Bacula – Offener Themenbereich

● Planung der Backupstrategie

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

● Hardwareanforderung

● …

● …

● ...

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 1