Datensicherung mit Bareos — und eine Kopie außer Haus

Eine Sicherung, die niemand zurückspielt, ist eine Hoffnung. Seit dem 24. August 2026 sichert Bareos meine gesamte Umgebung, seit dem 8. September liegt jede Nacht eine Kopie in einem anderen Rechenzentrum, und seit dem 10. September prüft ein automatischer Test, ob sich daraus auch etwas wiederherstellen lässt.

Aufbau

Bareos läuft auf einer eigenen Maschine, bareos00, mit eigener Platte für die Sicherungsdaten und einem lokalen PostgreSQL als Katalog. Die Konfiguration schreibt niemand von Hand: jeder Host meldet über Puppet an, was von ihm gesichert werden soll — Client, Job, FileSet, Pool. Der Director sammelt diese Angaben ein. Eine neue Maschine ist damit im Backup, sobald sie in der Konfigurationsverwaltung steht, und eine abgebaute verschwindet daraus.

Grundsätzlich wird die ganze Maschine gesichert. Was nicht hineingehört, markiert eine Datei .nobackup im jeweiligen Verzeichnis. Puppet legt diese Marken aus der Konfiguration an, entfernt aber nur, was es ausdrücklich entfernen soll — eine Marke, die jemand von Hand gesetzt hat, bleibt.

Datenbanken werden nicht als Dateien im laufenden Betrieb kopiert, sondern liegen vor dem Job als Auszug bereit: PostgreSQL per pg_dumpall, SQLite versioniert und mit Integritätsprüfung, dazu das Sicherungsskript von mailcow und die Auszüge des MySQL-Servers. Scheitert dieser Vorlauf, scheitert der ganze Job. Eine Sicherung mit kaputtem Datenbankauszug soll nicht grün aussehen.

Die Vollsicherung jeder Maschine läuft einmal pro Woche an einem eigenen Tag, die Startzeiten sind über zwei Stunden gestreut. Die Aufbewahrung regelt allein der Pool; die alten Einstellungen am Client hat Bareos ohnehin abgekündigt.

Ergebnisse landen in der Überwachung

Nach jedem Job meldet der Director das Ergebnis über die API an Icinga. Bleibt eine Meldung aus, wird die Prüfung nach Ablauf ihres Zeitfensters von selbst rot — eine Sicherung, die gar nicht erst läuft, fällt genauso auf wie eine, die scheitert. Dazu kommen eine stündliche Prüfung der Konfiguration, ein Alarm bei mehr als einer Vollsicherung desselben Hosts in 24 Stunden und eine Liste der Sicherungen, die noch keine Kopie außer Haus haben.

Die Prüfung auf doppelte Vollsicherungen hat einen Grund: Am ersten Tag lief für den Medienserver zweimal eine volle Sicherung über je rund 770 GB.

Die Kopie außer Haus

Alles auf einem Host im selben Rechenzentrum ist genau so sicher wie dieses Rechenzentrum. Seit dem 8. September steht deshalb ein zweiter Storage Daemon bei Hetzner in Helsinki, mit einer Storage Box am selben Standort. Jede Nacht um 4 Uhr, nach dem Sicherungsfenster, kopieren Copy Jobs die neuen Sicherungen dorthin. Die erste Nacht hat den gesamten Bestand übertragen, rund 138 GB.

Der Katalog geht getrennt mit: ein täglicher Auszug der Datenbank, seit dem 6. Oktober zusammen mit der Liste aller Volumes, die es laut Katalog geben müsste. Damit lässt sich im Ernstfall Bareos neu aufsetzen und prüfen, ob draußen alles liegt, was liegen soll.

Das Sicherungsziel liegt bewusst nicht auf den Nameservern, die ebenfalls bei Hetzner stehen: Es soll eine Maschine sein, die nichts anderes tut.

Rücksicherung als Prüfung

Seit dem 10. September stellt ein Test regelmäßig eine Datei wieder her — einmal aus der lokalen Sicherung, einmal aus der Kopie in Helsinki — und vergleicht sie mit der Prüfsumme im Katalog. Auf dem Weg dahin lernte ich, dass der Katalog MD5-Werte ohne das abschließende Base64-Padding speichert und dass Bareos beim ersten Versuch ungefragt aus der Kopie las statt aus dem lokalen Pool.

Aufbewahrung: 7 statt 30 Tage außer Haus

Zunächst hielt die Kopie außer Haus 30 Tage, wie die lokale Sicherung. Am 5. Oktober habe ich das auf 7 Tage gesenkt. Die Kopie ist für den Fall da, dass der Standort weg ist — dann zählt der letzte brauchbare Stand, nicht die Historie. Die Historie liegt lokal.

Die Rechnung dahinter ist schlicht: Bedarf = Volumegröße × Hosts + Tage × tägliche Menge. Bei 24 Hosts und knapp 20 GB pro Tag ergab das rund 1 070 GB bei 30 Tagen und 20-GB-Volumes, mit 7 Tagen und 5-GB-Volumes noch rund 260 GB.

Als der Speicher außer Haus volllief

Mitte Oktober war die Storage Box zu 93 % voll, obwohl die Rechnung weit darunter lag. Die Zahl der Kopierjobs war binnen einer Woche von 4 auf über 300 gestiegen. Nach dem Neuaufbau von bareos00, einem geleerten Ziel und einem sauberen Testlauf war klar: kein Fehler in Bareos. Volumes, deren Aufbewahrung abgelaufen war, behielten ihre Daten, weil Action On Purge = Truncate erst wirkt, wenn das Volume das nächste Mal ausgewählt wird. Rund 106 GB lagen so herum, ohne gebraucht zu werden. Eine eigene Prüfung meldet solche Volumes jetzt. Ob das Abschneiden im normalen Betrieb von allein greift, zeigt sich, wenn am 20. Oktober der erste volle Aufbewahrungszyklus endet.

Was ich daraus mitnehme

• Konfiguration aus der Verwaltung, nicht von Hand. Eine vergessene Maschine ist der häufigste Grund für eine fehlende Sicherung.
• Ausbleibende Ergebnisse sind Ergebnisse. Eine Prüfung, die nur auf Fehlermeldungen wartet, bemerkt nicht, dass gar nichts mehr läuft.
• Aufbewahrung ausrechnen, nicht schätzen — und nachmessen, ob die Wirklichkeit der Rechnung folgt.