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.
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.
Diesen Artikel als PDF kaufen
Express-Kauf als PDF
Umfang: 3 Heftseiten
Preis € 0,99
(inkl. 19% MwSt.)
Als digitales Abo
Weitere Produkte im Medialinx Shop »
Versandartikel
Onlineartikel
Alle Rezensionen aus dem Linux-Magazin
- Buecher/07 Bücher über 3-D-Programmierung sowie die Sprache Dart
- Buecher/06 Bücher über Map-Reduce und über die Sprache Erlang
- Buecher/05 Bücher über Scala und über Suchmaschinen-Optimierung
- Buecher/04 Bücher über Metasploit sowie über Erlang/OTP
- Buecher/03 Bücher über die LPI-Level-2-Zertifizierung
- Buecher/02 Bücher über Node.js und über nebenläufige Programmierung
- Buecher/01 Bücher über Linux-HA sowie über PHP-Webprogrammierung
- Buecher/12 Bücher über HTML-5-Apps sowie Computer Vision mit Python
- Buecher/11 Bücher über Statistik sowie über C++-Metaprogrammierung
- Buecher/10 Bücher zu PHP-Webbots sowie zur Emacs-Programmierung
Insecurity Bulletin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...





