Open Source im professionellen Einsatz

Bacula

Für die gestellte Aufgabe kann ich Bacula [6] empfehlen, weil Sicherungsintervall und -level schon sinnvoll vorkonfiguriert sind: Montag bis Samstag inkrementell, erster Sonntag im Monat Vollsicherung und die übrigen Sonntage differenziell. Das muss ich nur leicht abändern. Um Bacula anzuweisen, auf ein NAS zu schreiben, mounte ich das entfernte Verzeichnis per NFS und gebe es als Sicherungsverzeichnis in der »bacula-sd.conf« an. Wer die volle Kontrolle über das NAS hat, kann sogar auf diesem Baculas Storage-Daemon »bacula-sd« installieren.

Das in Listing 2 gezeigte Setup habe ich zusammen mit Philipp Storz entworfen, dem Autor des demnächst erscheinenden "Bacula"-Buches [7]. Es definiert die Pools »daily« und »weekly« , die kombiniert höchstens 15 Archivdateien (bei Bacula "Volumes") mit je 100 GByte Größe entstehen lassen. Nach und nach überschreibt Bacula ältere Volumes.

Listing 2

Bacula-Konfiguration

01 # Weekly Pool definition
02 Pool {
03   Name = weekly
04   Label Format = "weekly-"
05   Pool Type = Backup
06   Recycle = yes
07   AutoPrune = yes
08   Volume Retention = 14 weeks     # Wer weniger Puffer zur Sicherheit haben möchte, kann die Vorhaltezeit der Vollsicherungen erhöhen.
09   Maximum Volume Bytes = 100 GB
10 #  Maximum Volumes = 15           # Ist nicht unbedingt notwendig, da Volume Retention ausreicht. Mit Maximum Volumes muss man u.U. sogar häufiger manuell eingreifen.
11   Volume Use Duration = 23 hours
12 }
13
14 # Daily Pool definition
15 Pool {
16   Name = daily
17   Label Format = "daily-"
18   Pool Type = Backup
19   Recycle = yes
20   AutoPrune = yes
21   Volume Retention = 31 days     # gleiches wie oben
22   Maximum Volume Bytes = 1 GB
23 #  Maximum Volumes = 32          # gleiches wie oben
24   Volume Use Duration = 23 hours
25 }
26
27 # Im Schedule Differential auskommentieren:
28 Schedule {
29   Name = "WeeklyCycle"
30   Run = Full sun at 23:05
31 #  Run = Differential 2nd-5th sun at 23:05
32   Run = Incremental mon-sat at 23:05
33 }
34
35 # Standardmäßig soll Bacula das Pool daily nutzen, Vollsicherungen sollen im Full Pool "weekly" landen:
36 JobDefs {
37   Name = "DefaultJob"
38   Type = Backup
39   Level = Incremental
40   Client = course-fd
41   FileSet = "Full Set"
42   Schedule = "WeeklyCycle"
43   Storage = File
44   Messages = Standard
45   Full Backup Pool = weekly
46   Incremental Backup Pool = daily
47   Pool = daily
48   Priority = 10
49   Write Bootstrap = "/home/course/bacula/working/%c.bsr"
50 }

Noch zwei Tipps: In der Clientkonfiguration empfiehlt sich »Auto Prune« auf »no« zu setzen. Dies vermeidet, dass Bacula Datei-Informationen nach 30 Tagen aus seinem Katalog entfernt. Eine gute Idee ist es auch, sich die Bootstrap-Datei der Katalogsicherung im Katalogbackup-Job per E-Mail schicken oder auf NAS sichern zu lassen. Das gelingt per Skript im »RunAfterJob« . Fällt der Backupserver aus, kann ich mit der Bootstrap-Datei den Bacula-Katalog bequem wiederherstellen.

Erol Akman ist zertifizierter Bacula Instructor bei der Firma Dass IT GmbH.

Erol Akman ist zertifizierter Bacula Instructor bei der Firma Dass IT GmbH.

Online PLUS

Bacula-Spezialist Erol Akman hat den Backupverlauf in ein hübsch animiertes PDF gepackt, das sich (nur) im Adobe Reader anschauen lässt. Download unter: http://www.linux-magazin.de/plus/2012/05

BRU

Mein Beispielsetup für BRU [8] geht von diesen Annahmen aus: Backupmedium ist ein gemounteter, 4 TByte großer Raid-5-Storage, auf dem im wöchentlichen Full Backup insgesamt 400 GByte Daten von 30 Clientsystemen mit geschätzten 5 GByte täglichem Änderungsvolumen für inkrementelle Backups anfallen.

Acht Wochen sollen die Vollbackups erhalten bleiben, zwei Wochen die inkrementellen. Wir legen dafür zwei Nutzer an: »Full« der Besitzer der wöchentlichen Komplettbackups und »Inc« für die täglichen inkrementellen Sicherungen.

  • Im »Preferences« -Dialog setze ich die »Max Stage Age« auf 56 Tage (8 Wochen).
  • Unter »Open Data Manager | Users« setze ich »Max Stage Age« auf 56 Tage für den User »Full« , für »Inc« auf 14.
  • Dann erstelle ich die Backup-Definitionen und -Schedules: »New...« erzeugt einen neuen Backupjob, sein Ziel (»Destination« ) lasse ich auf »Stage Disk« zeigen, der Backuptyp ist »Full« , der Jobtyp »Backup« , das »Overwrite Setting« veranlasst den BRU-Server alte Backups zu überschreiben.
  • Jetzt noch den Eigentümer »Full« angeben, »OK« klicken, die Clients (und deren Daten) auswählen und speichern (»Save« ).
  • Als Nächstes stelle ich ein, wie oft das Backup erfolgen soll (wöchentlich).
  • Das tägliche, inkrementelle Backup entsteht aus einer (umbenannten) Kopie der oben erzeugten wöchentlichen Komplettsicherung mit einem anderen User, Namen, Intervall (täglich, nach den üblichen Arbeitszeiten) und Backuptyp (inkrementell).

Als Ergebnis habe ich jetzt ein vollständiges Backup, das jeden Freitag mit der Userkennung »Full« auf der Platte landet. Zusätzlich dazu gibt es ein tägliches inkrementelles Backup auf dem Server (User »Inc« ). Ersteres wird 56 Tage aufbewahrt, die täglichen Backups nur 14 Tage. Der BRU-Server löscht die Sicherungen vollautomatisch, sobald sie dieses Alter erreichen.

Tim Jones, President and CTO of TOLIS Group Inc., beschäftigt sich seit 1982 mit den Prozessen um Datenbackup and Restore. Seit 1994 gehört er zum BRU-Team.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 3 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook