Backups sind wichtig. Das wei\u00df mittlerweile jedes Kind. Daher setze ich hier zur Sicherung meiner Server schon seit l\u00e4ngerem Bacula und seit k\u00fcrzerem auf einem zweiten System Bareos, einen Bacula-Fork, ein. Man muss zwar anf\u00e4nglich etwas Hirnschmalz in die Konfiguration investieren, aber dann laufen beide Systeme ohne weiteres Eingreifen und machen genau das was sie sollen. Und das verdammt zuverl\u00e4ssig. F\u00fcr alle Maschinen die sich regelm\u00e4\u00dfig vom Backup-Server erreichen lassen ist diese L\u00f6sung somit optimal.<\/p>\n\n\n\n
Aber was macht man mit Ger\u00e4ten, welche sich nicht kontinuierlich im \u201eheimischen Netz\u201c befinden, sondern gerne auch mal auf Reisen und damit auch in anderen Netzen unterwegs sind, sprich Notebooks?<\/p>\n\n\n\n
Vor diesem Problem stand ich nun. Google f\u00f6rderte zwar den einen oder anderen L\u00f6sungsvorschlag zu Tage, aber keiner davon gefiel mir wirklich gut. Daher war wieder \u201eHirnschmalz investieren\u201c angesagt, und nun m\u00f6chte ich euch an meiner L\u00f6sung teilhaben lassen. Vielleicht gef\u00e4llt mein Ansatz ja dem einen oder anderen und erspart dann etwas Zeit und M\u00fche. Ich w\u00fcrde mich auf jeden Fall freuen.<\/p>\n\n\n\n
Ich setze f\u00fcr den weiteren Text zumindest Grundwissen beim Einrichten und Betrieb von Bacula \/ Bareos voraus, schreibe also kein Einsteigertutorial. Die gibt es zur Gen\u00fcge und auch die Doku beider Systeme ist sehr ergiebig. Ich gehe davon aus, das Bareos bereits l\u00e4uft und auf dem Notebook ein File-Daemon installiert und passend zum Server konfiguriert ist.
Au\u00dferdem sollten Grundkenntnisse bei der Arbeit mit Linux und diversen Diensten (z.B. ssh, cron, …) vorhanden sein.<\/p>\n\n\n\n
Auch wenn ich im weiteren Verlauf von Bareos schreibe, gilt alles auch f\u00fcr Bacula.<\/p>\n\n\n\n
Folgende Punkte sind mir wichtig:<\/p>\n\n\n\n
Grunds\u00e4tzlich wird das Sicherungsintervall ja durch den Bareos-Direktor gesteuert. In dessen Konfiguration wird hinterlegt was wann, wo und wie gesichert wird.<\/p>\n\n\n\n
Dieses Vorgehen ist f\u00fcr Server und auch fest installierte Desktop-Rechner spitze, st\u00f6\u00dft bei Notebooks jedoch auf Probleme, wenn diese zum Zeitpunkt der geplanten Sicherung gerade mal wieder unterwegs sind. Bareos wartet hier bei Abwesenheit des Ger\u00e4tes bis zum Timeout und protokolliert dann einen Fehler. Das sieht irgendwie unsch\u00f6n aus und sp\u00e4testens nach der 5 E-Mail vom Bareos-Direktor nervt das auch, und alles nur, weil der Kollege gerade mal wieder einige Tage auf Dienstreise ist.<\/p>\n\n\n\n
Da es, wie gerade beschrieben, problematisch ist das Backup f\u00fcr Notebooks vom Direktor steuern zu lassen, besteht meine Idee jetzt darin, dem Direktor diese Aufgabe zu entziehen und dem Notebook selbst zu \u00fcbertragen.<\/p>\n\n\n\n
Dieses kann beim Auftreten bestimmter Ereignisse pr\u00fcfen ob der Bareos-Server erreichbar ist und im Erfolgsfall den Bareos-Direktor anweisen das Backup zu starten.<\/p>\n\n\n\n
Als Ereignisse zum Triggern der \u00dcberpr\u00fcfung und des Backupstarts fallen mir jetzt spontan der Aufbau der Netzwerkverbindung oder auch das Timing per Cronjob ein. So soll das nachfolgend auch umgesetzt werden.<\/p>\n\n\n\n
Fangen wir mit dem Server an. Wir entziehen dem Bareos-Direktor im ersten Schritt die Steuerung des Backup f\u00fcr das Notebook. Dazu tilgen wir den starren Zeitplan aus der Konfiguration indem wir im entsprechenden Schedule einfach alle \u201eRun-Direktiven\u201c entfernen bzw. auskommentieren. Sollte ein Schedule verwendet werden, welches auch f\u00fcr andere Backup-Jobs ben\u00f6tigt wird, erstellt man einfach ein neues ohne Run-Direktiven und passt die Konfiguration entsprechend an. Nach einem Neustart des Bareos-Direktors, bzw. reload in der bconsole gibt es dann auch keine Meldung mehr \u00fcber fehlgeschlagene Backupversuche bei abwesendem Notebook. Leider wird jetzt aber auch kein automatisches Backup mehr erzeugt. Also erstmal nur die halbe Miete.<\/p>\n\n\n\n
Da Bareos selbst keine direkte M\u00f6glichkeit bietet Jobs per Skript zu starten und\/oder zu stoppen, m\u00fcssen wir f\u00fcr das weiter Vorgehen die M\u00f6glichkeit nutzen, das Programm „bconsole“ per Pipe zu steuern. Dazu habe ich mir ein kleines Bash-Skript \u201ebareos-remote.sh\u201c (Listing 1) geschrieben. Dieses Skript liegt hier im Verzeichnis \/etc\/bareos\/ und nimmt auf der Kommandozeile 2 Parameter entgegen. Einmal die gew\u00fcnschte Aktion (start oder stop) und dann den Namen des entsprechenden Jobs.<\/p>\n\n\n\n