Über den Author / Internet / Server / Bacula – Open Source Backupsystem

Bacula – Open Source Backupsystem

~5 Min. Lesezeit

Wenn man sich auf die Suche nach einem geeignetem Backupsystem für Linux Server macht, hört man leider zu oft die Antwort TAR.

Mit TAR kann man sehr schnell und einfach ein Verzeichnis sichern und im Notfall wieder entpacken und die Daten wiederherstellen.

Leider hat TAR ein sehr grosses Nachteil zu anderen Packungsprogrammen. Wenn ein TAR Paket ein Defekt ausweist, kann das komplette Paket nicht mehr entpackt oder repariert werden. Datenfehlern innerhalb von TAR Archiven sind somit ein Risiko was nicht zu unterschätzen ist, vor allem wenn man die Backups auf Tapes oder DVD’s auslagert. Dieses Problem haben andere Packprogramme wie ZIP oder RAR nicht.

Für mich ist aber eine ZIP und RAR Lösung keine Backuplösung. Backuplösungen sollen von Haus auf das komplette System und die Daten regelmässig backupen und kontrollieren, bei Fehlern informieren und das Wichtigste: Das Restore muss einfach und schnell laufen.

In meinem Fall suchte ich zusätzlich ein kostenloses oder zumindest kostengünstiges Produkt.

Gefallen hat mir Bacula. Vergleichen mit anderen Backupsystemen unter Linux ist es einfacher zu konfigurieren, aber stellte dennoch eine Hürde dar.

Installieren kann man Bacula über den Befehl:

apt-get install bacula bacula-director-mysql zlib1g-dev

Er wird dann zusätzliche Pakete vorschlagen, wichtig ist, das man den MySQL Director installiert, anderenfalls wird Bacula eine Postgre Datenbank erstellen.

Nun kommt der schwere Teil, die Konfiguration:

/etc/bacula/bacula-dir.conf

Director { # define myself
Name = MyServer-dir
DIRport = 9101 # where we listen for UA connections
QueryFile = "/etc/bacula/scripts/query.sql"
WorkingDirectory = "/var/lib/bacula"
PidDirectory = "/var/run/bacula"
Maximum Concurrent Jobs = 1
Password = "" # Console password
Messages = Daemon
DirAddress = 127.0.0.1
}
Client {
Name = MyServer-fd
Address = localhost
FDPort = 9102
Catalog = MyCatalog
Password = "" # password for FileDaemon
File Retention = 30 days # 30 days
Job Retention = 2 months # two months
AutoPrune = yes # Prune expired Jobs/Files
}
Storage {
Name = "MyDisk"
# Do not use "localhost" here
Address = 127.0.0.1
SDPort = 9103
Password = ""
Device = FileStorage
Media Type = File
}
Catalog {
Name = MyCatalog
dbname = "bacula"; dbuser = "bacula"; dbpassword = ""
}
Messages {
Name = Standard
mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: %t %e of %c %l\" %r"
operatorcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: Intervention needed for %j\" %r"
mail = root@localhost = all, !skipped
operator = root@localhost = mount
console = all, !skipped, !saved
append = "/var/lib/bacula/log" = all, !skipped
}
Messages {
Name = Daemon
mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula daemon message\" %r"
mail = root@localhost = all, !skipped
console = all, !skipped, !saved
append = "/var/lib/bacula/log" = all, !skipped
}
Pool {
Name = SystemBackup
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 70 days
Maximum Volume Bytes = 6G
LabelFormat = sysbackup_
}
Console {
Name = MyServer-mon
Password = ""
CommandACL = status, .status
}
FileSet {
Name = "Komplettes System"
Include {
File = /
Options {
signature = MD5
}
}
Exclude {
File = /root/backups/system
File = /var/spool/havp
File = /lib/init/rw
File = /proc
File = /dev
File = /cdrom
File = /tmp
File = /mnt
File = /.journal
File = /.fsck
}
}
Schedule {
Name = "Monatlich Voll – All 2 Wochen inkremental"
Run = Level=Full 1st sun at 01:01
Run = Level=Incremental 2nd-5th sun at 01:01
}
Job {
Name = SysBackup
Type = Backup
Client = MyServer-fd
FileSet = "Komplettes System"
Schedule = "Monatlich Voll – All 2 Wochen inkremental"
Storage = MyDisk
Pool = SystemBackup
Messages = Standard
Run After Job = /root/cron/backup_bacula.sh
}
Job {
Name = SysRestore
Type = Restore
Client = MyServer-fd
FileSet = "Komplettes System"
Where = /
Storage = MyDisk
Pool = SystemBackup
Messages = Standard
}

/etc/bacula/bacula-fd.conf

Director {
Name = MyServer-dir
Password = ""
}
Director {
Name = MyServer-mon
Password = ""
Monitor = yes
}
FileDaemon { # this is me
Name = MyServer-fd
FDport = 9102 # where we listen for the director
WorkingDirectory = /var/lib/bacula
Pid Directory = /var/run/bacula
Maximum Concurrent Jobs = 20
FDAddress = localhost
}
Messages {
Name = Standard
director = MyServer-dir = all, !skipped, !restored
}

/etc/bacula/bacula-sd.conf

Storage { # definition of myself
Name = MyServer-sd
SDPort = 9103 # Director’s port
WorkingDirectory = "/var/lib/bacula"
Pid Directory = "/var/run/bacula"
Maximum Concurrent Jobs = 20
Director {
Name = MyServer-dir
Password = ""
}
SDAddress = 127.0.0.1
}
Director {
Name = MyServer-mon
Password = ""
Monitor = yes
}
Device {
Name = FileStorage
Media Type = File
Archive Device = /root/backups/system/
LabelMedia = yes
Random Access = yes
AutomaticMount = yes
RemovableMedia = no
AlwaysOpen = no
}
Messages {
Name = Standard
director = MyServer-dir = all
}

/etc/bacula/bconsole.conf

Director {
Name = localhost-dir
DIRport = 9101
address = localhost
Password = "" # Console password
}

/etc/bacula/tray-monitor.conf

Monitor {
Name = localhost-mon
Password = "" # password for the Directors
RefreshInterval = 5 seconds
}

Client {
Name = localhost-fd
Address = localhost
FDPort = 9102
Password = "" # password for FileDaemon
}

Storage {
Name = localhost-sd
Address = localhost
SDPort = 9103
Password = "" # password for StorageDaemon
}

Director {
Name = localhost-dir
DIRport = 9101
address = localhost
}

In den Configfiles oben, sind die Passwörter per Zufallsmechanismus erstellt und ändern sich bei jedem Seitenaufbau, daher dürfen die Skripte 1:1 kopiert werden bei Bedarf.

Nach dem man die Konfiguration abgeschlossen hat (in meinem Beispiel ein monatliches Fullbackup und jede 2te Woche ein Inkremental dazu), muss man Bacula noch neu starten, damit die neue Konfiguration geladen wird mit:

/etc/init.d/bacula-fd restart
/etc/init.d/bacula-sd restart
/etc/init.d/bacula-director restart

Sobald dies abgeschlossen ist, läuft Bacula an und wird dann immer am Sonntag das nötige Backup starten.

Leider ist es damit aber nicht ganz gemacht, um ein Backup wiederherstellen zu können benötigt Bacula die Datenbank und eine Konfiguration. Sichert man also zusätzlich nicht die Bacula Datenbank, wird man Probleme beim Restore haben. In meinen Skripten oben ist bereits vorgesorgt, das nach jedem Backup folgendes Script aufgerufen wird:

#!/bin/bash
#############################################################
# Bacula MySQL Datenbank sichern
mysqldump −−opt −−user=bacula −−pass= bacula > /root/backups/system/`date +%y%m%d`_bacula.sql;
tar cfvz /root/backups/system/`date +%y%m%d`_bacula_db.tar.gz /root/backups/system/`date +%y%m%d`_bacula.sql > /dev/null 2>&1
rm /root/backups/system/`date +%y%m%d`_bacula.sql

tar -czf /root/backups/system/`date +%y%m%d`_bacula_etc.tar.gz /etc/bacula;
#############################################################

Das Script sichert die Konfiguration und die Datenbank, damit nichts für ein Restore im Weg liegt.


Viele User richten Backups ein und prüfen nie unter realen Bedingungen ein Restore. Ich durfte davon leider unfreiwilligen Gebrauch machen.
Nach dem Aufsetzen des Debian Grundbetriebsystemes, kann man Bacula mit dem apt-get Befehl (siehe Anfang) installieren und anschliessend die Konfigurationsdateien vom Backup wiederherstellen.

Das Backup von der MySQL Datei kann mit

mysql --user=root --pass= bacula < bacula.sql

eingespielt werden. Ist dies gemacht, restartet man Bacula nochmals komplett und kann dann über die bacula-console oder das Webmin Bacula Modul ein Restore initialisieren.

Ich empfehle dabei das Webmin Modul, weil man dann über eine grafische Weboberfläche sehr einfach den Restore starten kann.

Zur Überraschung ist definitiv zu sagen, das Bacula extrem schnell ist. Mein Restore von über 6 GB Daten hat rund 5 Minuten gedauert. Nach einem Serverrestart, war alles wiederhergestellt ohne Probleme.

Falls beim Restore der Fortschritt hängen bleibt über 30 Sekunden, dann ist etwas in der Konfiguration falsch, leider bringt es keine Fehler aus.

Ich empfehle selbstverständlich die Backups per rsync auszulagern, damit bei einem Hardwareausfall die Backups noch vorhanden sind.

About Stefan

avatar
Ein männlicher IT Nerd, durchstöbert das Web nach speziellen Gadgets, unentbehrlicher Software und Alles was man im IT Sektor nicht verpassen darf.Immer hilfsbereit wenn Probleme zu lösen sind oder das Unmögliche umgesetzt werden sollte.

Weitere interessante Artikel

Microsofts Mail-Sperre aufheben

~1 Min. LesezeitMicrosoft bannt im Moment einige IP Bereiche, weil von vereinzelten IP Adressen Spam …

Mailversand über mehrere IP Adressen per Postfix

~0 Min. LesezeitEin Linux System kann den Mailversand über mehrere IP Adressen managen. Dies hat …

7 Kommentare

  1. avatar

    hm, bist du sicher mit der Aussage, dass TAR problematisch bezüglich Fehlern ist? Ich will nichts behaupten, aber ich bin der Meinung, dass dies nur der Fall ist, wenn man es zusätzlich komprimiert. Tar ist ja ein Archiv und an sich nicht komprimiert. Es wurde ursprünglich für das Beschreiben von Tapes entwickelt und wäre ja dann immer problematisch, das kann ich mir so nicht vorstellen…
    Ansonsten prima Hilfe mit der Baruda Config! Danke…

  2. avatar

    GZip hat zwar eine Fehlererkennung über Checksummen eingebaut, beinhaltet aber keine Vorkehrungen zur Fehlerkorrektur. TAR hat nicht mal Checksummen für die Daten eingebaut. Ein defektes TAR Archiv wird deshalb nur als „confused“ erkannt, dann ist aber fertig.

    Es gibt zwar ein Tarfixer, aber dieser löscht einfach defekte Bereiche komplett raus und versucht zu retten was zu retten ist, dies kann aber keine Backuplösung sein 😉

    Mit Komprimierung über GZip verschlechtert sich die TAR Problematik zusätzlich ein wenig.

  3. avatar

    sorry, habe Mühe: sämtliche Backuplösungen, die auf Tape schreiben verwenden TAR. Also alle Daten werden sequenziel auf das Band geschrieben. Somit wären alle diese Backuplösungen (Veritas Netbackup etc.) nach Deiner Aussage nicht wirklich brauchbar 😉

    In deinem Beispiel von Baruda, werden alle Files sequenziell in ein FILE geschrieben

    Vielleicht liegt da der Unterschied. Sprich, wenn auf dem Band eine Sequenz defekt ist, kann der Rest trotzdem gelesen werden, was vielleicht bei einem Tar als File nicht oder nur bastelmässig möglich ist… Muss mal unsere Backup-Jungs fragen 😉

  4. avatar

    Es gibt diverse Weiterentwicklungen von TAR, welche Schutzmechanismen wie Checksummen eingebaut haben, genau um die sequentielle Wiederherstellung zu ermöglichen, welche du ansprichst.

    Bei einem Standard TAR kann der Verlust eines Sektors zum Gesamtverlust eines Archives führen:

    Weiterentwicklungen von TAR merzen die Probleme aus und werden gerne und sehr oft genutzt, so auch von Veritas. Solche Archive können dann jedoch auch mit dem Standard TAR Befehl entpackt aber nicht erzeugt werden.

    Bei den Archiven kann man dann auch sequentiell entpacken und nur die defekten Teile sind verloren. Viele User benutzen aber den Systembefehl tar um Backups zu machen, ohne zusätzliche Backuplösung.

    Auch ich hatte leider tar.gz erzeugt in Vergangenheit und bin froh endlich umgestiegen zu sein. Wer also auf Tapes sichert, verwendet meist ein Sicherungsprogramm, wo sich von Haus aus mit dem Tehma beschäftigte und vorsorgte. Personen wir ich wo per Systembefehl Backups erstellten und per rsync auslagern, haben aber Probleme.

  5. avatar

    ich glaube jetzt sind wir uns fast einig 😉 schönes Wochenende…

  6. avatar

    Hallo, habe da noch eine kleine Korrektur zu einem deiner Config-Files. Scheint, dass einige Zeilen „zerschossen“ waren.
    Es geht um /etc/bacula/bacula-sd.conf: (korrigiert)

  7. avatar

    Es war eine Zeile “ Maximum Concurrent Jobs = 20Director {“ drin, wo hätten 2 sein müssen „Maximum Concurrent Jobs = 20
    Director {„. Danke ist korrigiert.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

eMail-Benachrichtigung bei weiteren Kommentaren.
Auch möglich: Abo ohne Kommentar.

This Blog will give regular Commentators DoFollow Status. Implemented from IT Blögg