Tape Backups mit Bacula

Im Vergleich zu anderen Backupprogrammen wie obnam, bup, attic und rsnapshot ist Bacula ein Monstrum, welches zudem eine ziemlich steile Lernkurve hat. Die Dokumentation ist umfangreich aber nicht frei von Fehlern und/oder zumindest missverständlichen Formulierungen. Dennoch lohnt es sich sehr, sich mit Bacula zu befassen.

Zunächst sollte man sich also genau überlegen was man eigentlich genau mit seinem Backup erreichen möchte. Auf Basis dieser Überlegungen kann man dann entsprechende Pools (ein Set von 1-n Bändern) planen.

Wichtig ist hierbei, unter anderem, ein tieferes Verständnis der 3 Backupmodi von Bacula:

• Full
• Incremental
• Differential

Für jeden Modus können separate Bänder genutzt werden. Dies kann sehr sinnvoll sein, z.B. wenn das Backup Off-Site aufbewahrt werden soll. Man könnte z.B. einmal im Monat ein Full-Backup erstellen welches man in einem Bankschließfach unterbringt. Den Rest des Monats nutzt man dann andere Bänder für Incremental/Differential-Backups, die entweder in der Backup-Library verbleiben oder im täglichen Wechsel genutzt werden.

Der tägliche Wechsel erfordert einige Zusatzüberlegungen. Man könnte einen Pool mit der doppelten (besser dreifachen) Anzahl der eigentlich benötigten Bänder anlegen und dann immer die Hälfte davon entfernen. Hierzu muss man aber natürlich darauf achten welche Bänder welche Daten enthalten. Alternativ kann man zwei (besser drei) Pools nutzen, sollte dann aber auch zwei bzw. drei Full-Backups erzeugen, da die Pools nichts voneinander wissen.

Beide Lösungen sind nicht wirklich elegant. Es kann daher sinnvoll sein verschiedene Backuptechniken zu kombinieren. Zum Beispiel könnte man Bacula für Langzeitbackups verwenden und die Daten die sich tagtäglich ändern auf ein RDX-Laufwerk sichern. Sinnvollerweise sollten die Datenablagen (z.B. Samba-Shares) dies entsprechend widerspiegeln (z.B. Aktuelle Projekte und Archiv), damit ganz klar ist welche Daten täglich (Off-Site) gesichert werden müssen und welche nicht. Dies reduziert im Zweifel auch die nötigen Zeiten für ein Restore erheblich, wenn es (zumindest zunächst) ausreicht die tagesaktuellen Daten zurückzuspielen.

Ein weiterer Vorteil einer solchen Lösung ist es dass man den Catalog, in dem Bacula speichert welche Daten sich auf welchem Band befinden, so nochmals sichern kann ohne ein Band dafür nutzen zu müssen. Dies ist elementar wichtig, geht der Catalog verloren kann man diesen zwar mittels der Bänder neu auslesen, dies dauert aber mitunter sehr lange (Wochen).

Im nächsten Teil geht es dann um die einzelnen Bacula-Komponenten und deren Installation.

Bevor man ein Backup erzeugen kann muss natürlich Bacula mit dem entsprechenden Laufwerk verbunden werden, wir verwenden eine Tandberg T24. Eine Backup-Library mit 12-Slots für Bänder und einem internen Bandlaufwerk.

Zunächst sollten wir jedoch noch die einzelnen Bacula-Komponenten kennenlernen:

• Bacula Director (bacula-dir/bacula-director)
• Bacula Storage Daemon (bacula-sd)
• Bacula File Daemon (bacula-fd)
• Bacula Console (bacula-console/bconsole)
• Bacula Monitor (bacula-mon)
• Catalog

Der bacula-director ist die Schaltzentrale von Bacula. bacula-sd kümmert sich um den Datentransfer zum Backupmedium und die Ansteuerung der Backup-Library. bacula-fd übernimmt den Datentransfer der zu sichernden Daten an bacula-sd. Über die bconsole kann der bacula-director gesteuert, mittels bacula-mon überwacht, werden. Alle Speichervorgänge werden im Catalog gespeichert.

Jede der Komponenten kann auf dem gleichen Server installiert werden, es sich aber auch Setups möglich in denen separate Maschinen die einzelnen Aufgaben übernehmen. Dies ist insbesondere für bacula-sd praktisch, da dieser meist über spezielle Hardware zur Ansteuerung der Library verfügen muss und zudem während des Backups am meisten IO-Last zu tragen hat.

Vom bacula-director und bacula-sd existieren (zumindest unter Debian) mehrere Varianten, die sich jeweils in der verwendeten Datenbankanbindung unterscheiden. Am einfachsten ist die Nutzung von bacula-(director|sd)-sqlite3, welches aber nur für kleine Installationen genutzt werden sollte. Alternativ stehen bacula-(director|sd)-mysql und bacula-(director|sd)-pgsql zur Verfügung. Wir werden die MySQL-Variante nutzen und der Einfachheit halber installieren wir alle Komponenten auf nur einem Server (auf bacula-mon verzichten wir):

apt-get install bacula-director-mysql bacula-sd-mysql bacula-fd bacula-console

Im nächsten Teil geht es dann um die Grundkonfiguration und die Ansteuerung der Tandberg.

Bei der Konfiguration von Bacula geht man wohl am Besten gestaffelt vor. Zunächst wird bacula-sd eingerichtet und der bacula-director bekommt eine Minimalkonfiguration, damit die korrekte Funktion der Tape-Library getestet werden kann.

Verläuft hierbei alles korrekt können erste Pools definiert und die entsprechenden Tapes gelabelt werden. Mit dieser Konfiguration sind dann erste Backup-Jobs zu erzeugen und intensiv zu testen.

Als Basis nutzen wir die, bei der Installation der Debian-Pakete erzeugten, Konfigurationsdateien. Dies ist empfehlenswert da hier bereits einige Kennwörter hinterlegt sind die es den verschiedenen Diensten ermöglicht sich gegenseitig zu verbinden. Immerhin hat ein bacula-fd, in der Regel, Lesezugriff auf alle wichtigen Dateien eines Servers. Außerdem erspart man sich so eventuelle Falschzuweisungen von Kennwörtern die nicht immer auf den ersten Blick ersichtlich sind und so die Funktionsprüfung erschweren.

Die Konfiguration des Storage-Daemons erfolgt über die Datei /etc/bacula/bacular-sd.conf.

Zunächst ist der Wert SDAddress im Abschnitt Storage anzupassen. Hierbei handelt es sich um die IP, auf der der Storage-Daemon lauschen soll:

Storage {
Name = baculamaster-sd
SDPort = 9103
WorkingDirectory = “/var/lib/bacula”
Pid Directory = “/var/run/bacula”
Maximum Concurrent Jobs = 20
SDAddress = 192.168.1.101
}

Damit die Tape-Library angesprochen werden kann muss deren Drive und die Ansteuerung des Autochangers entsprechend konfiguriert werden:

Autochanger {
Name = Autochanger
Device = Drive-1
Changer Command = “/etc/bacula/scripts/mtx-changer %c %o %S %a %d”
Changer Device = /dev/sg2
}

Device {
Name = Drive-1
Media Type = LTO-5
Archive Device = /dev/nst0
AutomaticMount = yes;
AlwaysOpen = yes;
RemovableMedia = yes;
RandomAccess = no;
Maximum File Size = 5GB
Changer Command = “/etc/bacula/scripts/mtx-changer %c %o %S %a %d”
Changer Device = /dev/sg2
AutoChanger = yes
Alert Command = “sh -c ‘tapeinfo -f %c |grep TapeAlert|cat'”

Will man zunächst nur einige Erfahrungen mit Bacula selbst machen kann man auch ein File-Device nutzen:

Device {
Name = FileStorage
Media Type = File
Archive Device = /backup
LabelMedia = yes;
Random Access = Yes;
AutomaticMount = yes;
RemovableMedia = no;
AlwaysOpen = no;
}

Nun kann die Kommunikation mit der Tape-Library getestet werden, hierbei muss der bacula-sd allerdings beendet werden (/etc/init.d/bacula-sd stop), da er das Laufwerk sonst exklusiv in Beschlag nimmt:

btape -c /etc/bacula/bacula-sd.conf /dev/nst0

Tape block granularity is 1024 bytes.
btape: butil.c:290 Using device: “/dev/nst0” for writing.
13-May 13:33 btape JobId 0: 3301 Issuing autochanger “loaded? drive 0” command.
13-May 13:33 btape JobId 0: 3302 Autochanger “loaded? drive 0”, result is Slot 9.
btape: btape.c:477 open device “Drive-1” (/dev/nst0): OK

Nachdem btape gestartet wurde kann durch die Eingabe von test ein Testlauf gestartet werden. Ein Test des Autochangers kann mittels auto eingeleitet werden. Für einen erfolgreichen Test muss sich beim Start ein Band im Laufwerk befinden. Außerdem wird in Slot 1 ein beschreibares Band benötigt.

Siehe auch: http://www.bacula.org/5.2.x-manuals/en/problems/problems/Testing_Your_Tape_Drive.html

Informationen vom Media Changer können mit dem Befehl mtx abgefragt werden:

mtx -f /dev/sg2 status
Storage Changer /dev/sg2:1 Drives, 11 Slots ( 1 Import/Export )
Data Transfer Element 0:Full (Storage Element 9 Loaded):VolumeTag = A00008
Storage Element 1:Empty:VolumeTag=
Storage Element 2:Full :VolumeTag=A00001
Storage Element 3:Full :VolumeTag=A00002
Storage Element 4:Full :VolumeTag=A00003
Storage Element 5:Full :VolumeTag=A00004
Storage Element 6:Full :VolumeTag=A00005
Storage Element 7:Full :VolumeTag=A00006
Storage Element 8:Full :VolumeTag=A00007
Storage Element 9:Empty:VolumeTag=
Storage Element 10:Empty:VolumeTag=
Storage Element 11 IMPORT/EXPORT:Empty:VolumeTag=

Mittels mtx können z.B. Bänder in das Laufwerk eingelegt werden:

mtx -f /dev/sg2 load 8 0

mtx: Request Sense: Long Report=yes
mtx: Request Sense: Valid Residual=no
mtx: Request Sense: Error Code=0 (Unknown?!)
mtx: Request Sense: Sense Key=No Sense
mtx: Request Sense: FileMark=no
mtx: Request Sense: EOM=no
mtx: Request Sense: ILI=no
mtx: Request Sense: Additional Sense Code = 00
mtx: Request Sense: Additional Sense Qualifier = 00
mtx: Request Sense: BPV=no
mtx: Request Sense: Error in CDB=no
mtx: Request Sense: SKSV=no
Mode sense (0x1A) for Page 0x1D failed
Loading media from Storage Element 8 into drive 0…done

Anstelle von mtx kann auch das Bacula-Script /etc/bacula/mtx-changer verwendet werden, dieses wird später auch intern von Bacula verwendet.

/etc/bacula/mtx-changer /dev/sg2 load 2 /dev/nst0 0

Lädt das Band in Slot 2 in das Laufwerk 0.

Die Konfiguration des bacula-director muss zu diesem Zeitpunkt nicht angepasst werden.

Wenn bis hier alles korrekt funktioniert steht der weiteren Einrichtung von Bacula nichts im Wege, dies machen wir dann im nächsten Teil.

Der bacula-director ist die Steuerzentrale des Bacula-Systems. Hier werden alle Backupaufgaben und Zeitpläne definiert und gesteuert. Die Konfiguration teil sich u.a. in folgende Abschnitte:

• Jobs / JobDefs
• Schedules
• FileSets
• Pools
• Volumes
• Label

Ein Backup-Job besteht jeweils aus einem:

• FileSet
• Client
• Schedule
• Pool

Das FileSet beschreibt hierbei welche Daten zu sichern sind. Der Client gibt an wo sich diese Daten befinden. Der Schedule bestimmt zu welchen Zeiten das Backup erzeugt werden soll. Der Pool gibt an wo das Backup gespeichert werden soll (Volume). Ein Volume ist, in unserem Fall, ein physikalisches Bandlaufwerk. Ein Pool ist ein Set von Volumes.

Bevor ein Volume verwendet werden kann muss es mit einem Label versehen werden, damit Bacula Storage es einwandfrei identifizieren kann. Dies erfolgt mit dem Kommando label über die Bacula Konsole (bconsole).

Der Director selbst benötigt natürlich auch einige Konfigurationszeilen:

Director {
Name = baculamaster-dir
DIRport = 9101
QueryFile = “/etc/bacula/scripts/query.sql”
WorkingDirectory = “/var/lib/bacula”
PidDirectory = “/var/run/bacula”
Maximum Concurrent Jobs = 1
Password = “random_dir_password”
Messages = Daemon
DirAddress = 192.168.1.101
}

Wichtig ist hier insbesondere DirAddress (Bind-Address) und Password. Im QueryFile können SQL-Statements hinterlegt werden, die mittels bconsole aufgerufen werden können, z.B. um Abzufragen wann das letzte Full-Backup für einen bestimmten Client erzeugt wurde.

Nachdem der director selbst soweit konfiguriert ist, können wir unsere Clients hinzufügen (jeder Client benötigt das Paket bacula-fd):

Client {
Name = baculaclient1-fd
Address = 192.168.1.102
FDPort = 9102
Catalog = MyCatalog
Password = “random_fd_password”
}

Der Wert für Password muss mit dem Kennwort in der Konfiguration von bacula-fd auf dem jeweiligen Client übereinstimmen.

Nun können wir die ersten Jobs erzeugen. Da viele Jobs wiederkehrende Elemente aufweisen kann man diese in einer JobDefs definieren. Alle Jobs, die auf dieser Definition basieren, verwenden dann diese Einstellungen, sofern sie nicht explizit wieder überschrieben werden:

JobDefs {
Name = “DefaultJob”
Type = Backup
Level = Incremental
FileSet = “Full Set”
Schedule = “WeeklyCycle”
Storage = File
Messages = Standard
Pool = Default
Priority = 10
Write Bootstrap = “/var/lib/bacula/%c.bsr”
}

Job {
Name = “BackupClient1”
JobDefs = “DefaultJob”
Client = baculaclient1-fd
}
Job {
Name = “BackupClient2”
JobDefs = “DefaultJob”
Client = baculaclient2-fd
Priority = 11
}

Job {
Name = “RestoreFiles”
Type = Restore
FileSet=”Full Set”
Storage = File
Pool = Default
Messages = Standard
Where = /restore
}

Da die beiden Jobs auf der JobDefs basieren müssen wir hier nur die Abweichungen konfigurieren. Jeder Job benötigt einen eindeutigen Namen (Name). Außerdem weicht natürlich der Client ab. Zur Verdeutlichung wurde bei BackupClient2 eine abweichende Priority hinterlegt.

Der RestoreFiles-Job kann für alle Restores verwendet werden und muss daher nur einmal angelegt werden.

Nun benötigen wir noch ein FileSet:

FileSet {
Name = “Full Set”
Include {
Options {
signature = MD5
}
File = /
File = /media
}
Exclude {
File = /tmp
}
}

Es werden alle Dateien auf / gesichert. Da /media ein anderes Dateisystem beinhaltet wird es separat angegeben, andernfalls würde Bacula es übergehen. Im Bereich exclude wird /tmp vom Backup ausgenommen.

Fehlt noch ein Schedule:

Schedule {
Name = “WeeklyCycle”
Run = Full 1st sat at 00:05
Run = Differential 2nd-5th sat at 00:05
Run = Incremental mon-fri at 00:05
}

An jedem 1. Samstag im Monat wird um 00:05 ein Full-Backup erzeugt. Hierbei werden alle Daten neu auf das Band geschrieben. Jeden 2.-5. Samstag wird ein Differential-Backup erzeugt. Von Montag-Freitag um 00:05 ein Incremental, hierbei werden nur geänderte Daten hinzugefügt. Um eine komplette Wiederherstellung von Daten durchzuführen muss zunächst das aktuellste Full-Backup zurückgespielt werden, anschließend alle Incremental-Backups bis zum gewünschten Zeitpunkt. Um dies abzukürzen können Differential-Backups genutzt werden, hier ist das Restoreprozedere dann: aktuellstes Full-Backup -> aktuellstes Differential-Backup -> alle Incremental-Backups ab dem Differential-Backup, bis der gewünschte Stand erreicht ist.

Fehlt noch der Pool:

Pool {
Name = Default
Maximum Volumes = 3
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 12 hours
Catalog Files = yes
UseVolumeOnce = no
}

Der Pool darf maximal 3 Volumes (Bänder) verwenden. Nach frühestens 12 Stunden, nachdem das letzte Backup auf eines der Pool-Volumes geschrieben wurde, dürfen sie wiederverwendet werden (Recycle und AutoPrune).

Zu Testzwecken bietet sich die Option Maximum Volume Bytes = 5G an, mit dieser kann die Größe eines Bands bestimmt werden, so kann getestet werden was bei einem vollen Band passiert ohne ggf. 1,5TB Daten darauf schaufeln zu müssen.

Abschließend muss noch die Verbindung zum Storage-Daemon (bacula-sd) hinzugefügt werden:

Storage {
Name = Tape
Address = 192.168.0.3
SDPort = 9103
Password = “random_sd_password”
Media Type = LTO-5
AutoChanger = yes
Device = T24
Maximum Concurrent Jobs = 1
AllowCompression = yes
}

Um die Änderungen zu Aktivieren muss der bacula-dir neu gestartet werden.

Siehe auch:

http://www.bacula.org/5.2.x-manuals/en/main/main/What_is_Bacula.html http://www.bacula.org/5.2.x-manuals/en/main/main/Getting_Started_with_Bacula.html http://www.bacula.org/5.2.x-manuals/en/main/main/Brief_Tutorial.html

Damit Bacula mit einem Tape arbeiten kann, muss dieses gelabelt werden. Hierbei werden einige Einstellungen für den Umgang mit dem Tape vorgenommen:

Retention Use Duration Max Volume Jobs Max Volume Bytes Max Volume Files Pool Recycle Pool Diese Werte werden teilweise aus der Director-Configuration gezogen, ändert man diese dort (z.B. Retention), müssen sie an allen betreffenden Tapes ebenfalls angepasst werden.

Der eigentliche Labelvorgang funktioniert über die bconsole die natürlich zunächst eingerichtet werden muss.

Director {
Name = baculamaster-dir
DIRport = 9101
address = 192.168.0.1
Password = “random_password”
}

Das Labeln funktioniert dann wie folgt:

bconsole
label barcodes slots=2 storage=Tape

Do you want to label these Volumes? (yes|no): yes

Connecting to Storage daemon Tape at 192.168.0.1:9103 …
3306 Issuing autochanger “slots” command.
Device “T24” has 11 slots.
Connecting to Storage daemon Tape at 192.168.0.1:9103 …
3306 Issuing autochanger “list” command.
The following Volumes will be labeled:

Slot Volume
2 A00006

Select the Pool (1-8): 1

Beim Labeln wird dem Tape also auch der zugehörige Pool zugewiesen. Das Beispiel oben geht davon aus, dass das Tape mit einem Barcode versehen wurde.

Mittels folgenden Befehlen kann ein Label wieder entfernt werden, falls ein Band beschädigt wurde oder einem anderen Pool zugeordnet werden soll:

mt -f /dev/nst0 rewind
mt -f /dev/nst0 weof
mt -f /dev/nst0 rewind

Das entsprechende Band muss natürlich zuvor in das Laufwerk geladen werden.

Damit mt auf das Band zugreifen kann muss zunächst der Storage-Daemon gestoppt werden (/etc/init.d/bacula-sd stop).

Alternativ kann der Konsolenbefehl relabel verwendet werden. Die Syntax: relabel storage= oldvolume= volume=.

Um ein Tape zu löschen kann ebenfalls die bconsole verwendet werden, im folgenden Beispiel wird das Tape A00006 gelöscht und in einem neuen Pool verfügbar gemacht.

bconsole
delete volume=A00006

Are you sure you want to delete Volume “A00006”? (yes/no): yes
This command will delete volume A00006
and all Jobs saved on that volume from the Catalog

update slots=2 drive=0 storage=Tape

Connecting to Storage daemon Tape at 192.168.0.1:9103 …
3306 Issuing autochanger “slots” command.
Device “T24” has 11 slots.
Connecting to Storage daemon Tape at 192.168.0.1:9103 …
3306 Issuing autochanger “list” command.
Volume “A00006” not found in catalog. Slot=2 InChanger set to zero.

label barcodes slots=2 storage=Tape

Do you want to label these Volumes? (yes|no): yes
Connecting to Storage daemon Tape at 192.168.0.1:9103 …
3306 Issuing autochanger “slots” command.
Device “T24” has 11 slots.
Connecting to Storage daemon Tape at 192.168.0.1:9103 …
3306 Issuing autochanger “list” command.
The following Volumes will be labeled:

Slot Volume
2 A00006

Select the Pool (1-8): 2

Hierbei werden alle Daten/Catalogeinträge für das Band entfernt und möglicherweise wird daher das nächste Backup als Full-Backup durchgeführt, auch wenn eigentlich ein Incremental/Differential geplant war.

Nachdem unsere Bacula-Installation nun hoffentlich funktioniert, hier noch einige Gedanken zur praktischen Umsetzung echter Backupszenarien.

Das Wichtigste zu Beginn: MACHT BACKUPS VOM CATALOG!

Es ist normalweise nicht meine Art Caps-Lock zu verwenden, aber hier ist es wirklich angebracht. Ja, man kann den Catalog-Inhalt von den Bändern restaurieren. Dies dauert aber im Zweifel Wochen, oder sogar Monate. Hat man kein zweites Laufwerk kann man in dieser Zeit keine neuen Backups erstellen. Ergänzend sollte man auch die sog. bootstrap-Dateien sichern, diese werden mittels der Directive Write Bootstrap = “/var/lib/bacula/%c.bsr” an einem Job/JobDef erzeugt. In diesen stehen Metadaten zu den Bändern, die ein Restore erleichtern, sollte der Catalog mal beschädigt werden.

Sinnvollerweise macht man das Backup des Catalogs nicht (nur) mittels Bacula. Wenn man keine andere Möglichkeit hat sollte man zumindest einen separaten Pool verwenden. Dann muss man bestenfalls nur ein kleines Tape auslesen und nicht mehrere 1,5 TB-Bänder.

Aber auch ohne den Verlust des Catalogs gibt es einige Stolperfallen.

Man sollte sich im Vorfeld gut überlegen welche Retention-Zeiträume für die Bänder und ihre Daten sinnvoll sind. Zu lange Zeiträume verbrauchen unnötig viel Speicherplatz auf den Tapes, blähen den Catalog auf und machen ein Restore unübersichtlich. Zu kurze Zeiträume machen im Zweifel häufige Full-Backups notwendig, schlimmstenfalls mitten in der Woche, bei Laufzeiten über 24 Stunden.

Auch wenn es eine zusätzliche Hürde sein mag, sollte man sich mit der Text-Console (bconsole) anfreunden. Auch die Tools mt, mtx-changer, btape, bscan sollte man sich einmal etwas genauer ansehen. Die bacula-console-qt hilft zwar am Anfang, da mein keine Befehle lernen muss, allerdings ist sie auch oft instabil oder wartet einfach ewig auf eine Rückmeldung vom Director. Wenn einmal gar nichts mehr geht hilft auch oft ein Neustart der Library selbst.

Will man ein tagesaktuelles Backup Offsite lagern stellt sich schnell die Frage wie man dies sinnvoll bewerkstelligt. Hier ist es verführerisch einfach alle Jobs zu klonen und einfach zwei Sätze von Tapes zu verwenden. Das Problem hierbei, die einzelnen Jobs wissen nichts voneinander. Doppelte Anzahl Jobs = doppelt so großer Catalog. Außerdem kann es Probleme geben wenn man auf Satz 1 noch ein Full-Backup hat, aber auf Satz 2 nicht mehr. Will man dann auf Satz 2 ein neues Incremental-Backup erzeugen, wird automatisch ein Full-Backup-Job verwendet. Dieser braucht im Zweifel aber länger als 24 Stunden, womit sich der nächste Incremental-Job direkt im Anschluss einreiht, aber eigentlich auf Satz 1 erzeugt werden müsste. Nicht zuletzt benötigt man einen Mechanismus, der die Jobs, für den Satz, der gerade Offsite gelagert wird, abbricht, wenn die nötigen Tapes nicht zur Verfügung stehen. Ein Scratch-Pool (ein Pool mit Tapes aus denen sich Bacula bedienen kann, wenn für einen anderen Pool ein weiteres Tape benötigt wird) hilft hier nicht, da man irgendwann duzende von Tapes mitnehmen müsste.

Besser ist es hier im jeweiligen Job einen Pool für Incremental/Differential-Backups und einen für Full-Backups zu definieren:

Pool {
Name = Full
Maximum Volumes = 4
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 3 Months
Catalog Files = yes
UseVolumeOnce = no
}
Pool {
Name = Inc
Maximum Volumes = 2
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 12 hours
Catalog Files = yes
UseVolumeOnce = no
}

JobDefs {
Name = “Backup”
Type = Backup
Level = Incremental
FileSet = “Full Set”
Schedule = “Daily”
Storage = Tape
Messages = Standard
Priority = 50
Write Bootstrap = “/var/lib/bacula/%c.bsr”
Pool = Full
}

Job {
Name = “Backup Offsite”
JobDefs = “Backup”
Client = bacula-fd
Incremental Backup Pool = Inc
Full Backup Pool = Full
Priority = 15
}

Durch die obige Konfiguration nutzt Bacula für ein Full-Backup bis zu 4 Tapes aus dem Pool Full. Incremental Backups werden auf max. 2 Tapes aus dem Pool Inc gespeichert. Die Full-Backups können nach 3 Monaten wieder überschrieben werden. Incremental Backups bereits nach 12 Stunden (die Werte müssen nicht unbedingt sinnvoll sein, sie dienen nur als Beispiel).

Bei Schedule könnte man nun, z.B. immer am Samstag ein Full-Backup erzeugen. Da dieses auf separaten Tapes gespeichert wird, kann man diese dann aus der Libaray entfernen und Offsite lagern. Die Incremental-Backups verbleiben stets in der Library. Daraus ergeben sich zwei Probleme:

Brennt die Firma an einem Wochenende ab, sind alle Daten verloren, da sich das Full-Backup ja in der Library befindet. Brennt die Firma ab, oder werden die Server gestohlen, hat man ein Backup mit dem Stand von vor einer Woche. Beides sind natürlich Punkte, vor denen ein Backup eigentlich schützen sollte. Punkt 1 kann man entschärfen, indem man stets 2 Full-Backups erzeugt. Reicht die Zeit hierfür nicht aus kann man im wöchentlichen Wechsel zwei Generationen von Tapes nutzen. Da die Incremental-Backups immer auf dem letzten Full-Backup aufbauen entsteht zwar auch hier im Zweifel eine kleine Lücke, aber das sollte in den meisten Fällen vernachlässigbar sein.

Was ist mit Punkt 2? Machen wir uns nichts vor, Tapes sind ein tolles Backupmedium, haben aber auch einige Nachteile. Einer davon ist die Zugriffszeit. Einzelne Dateien wiederherzustellen kann relativ lange dauern, und sei es nur, weil an die richtige Stelle gespult werden muss. Auch weil der Catalog gesichert werden muss bietet sich ein zweites Backupsystem, z.B. RDX-Laufwerke an. Wir nutzen diese um ein weiteres tagesaktuelles Backup zu erzeugen, so ist es weniger tragisch, wenn das Incremental-Backup verloren geht. Damit die Backupgröße überschaubar bleibt verschieben wir abgeschlossene Projekte in ein Archiv. Dieses wird nur auf Tape gesichert und sollte in den Full-Backups stets aktuell vorhanden sein.

100% Perfekt ist das Verfahren nicht, aber mal ehrlich, wenn die Firma abbrennt – oder alle Server gestohlen werden – hat man sowieso andere Probleme als ein paar fehlende/veraltete Dateien. Trotzdem sollte man sich natürlich im Vorfeld genau überlegen wie viel Risiko man hier verantworten kann.

Wer andere Ideen hat, kann sich natürlich gern in den Kommentaren zu Wort melden.

Wem das alles eh viel zu kompliziert ist und über eine ausreichend schnelle Internetanbindung verfügt kann natürlich auch alle Backupdaten auf einen externen Server schieben. Ein wirklich schönes Programm hierfür ist: https://attic-backup.org/