Im Beitrag State-of-the-Art Backups: Automatisiert mit Puppet, Restic und georedundantem S3 ging es um die Grundlage: standardisierte Backup-Jobs, Restic als Sicherungswerkzeug und ein selbstgehostetes, georedundantes S3-Ziel.
Der logische nächste Schritt ist aber nicht die Sicherung selbst, sondern ihre operative Überwachung. Denn Backups sind schnell als “vorhanden” markiert. Die wichtigere Frage lautet: Wann wurde im Zielsystem zuletzt tatsächlich ein neuer Stand geschrieben?
Genau an dieser Stelle entsteht in vielen Umgebungen eine Lücke. Jobs laufen laut Plan, Zielsysteme sind erreichbar und dennoch bleibt oft unklar, ob ein Repository auf dem Backup-Storage wirklich aktuell ist. Für den Betrieb ist das zu wenig.
Deshalb haben wir den bestehenden Backup-Ansatz um einen zusätzlichen Baustein erweitert: automatische Backup-Age-Checks für Restic-Repositories auf einem S3-kompatiblen Garage-Server.
Das Ziel: kein manuelles Nachpflegen pro Backup-Client
Der wichtigste Punkt war diesmal nicht nur der Check selbst, sondern die Art der Einbindung. Ein zusätzliches YAML-Objekt pro Kunde oder System wäre technisch machbar, aber auf Dauer unnötige Doppelpflege.
Darum folgt das Modul einem einfacheren Prinzip:
- bestehende Backup-Konfiguration bleibt die führende Quelle
- Monitoring-Checks werden daraus automatisch abgeleitet
- pro Backup-Client entsteht ein eigener Alterscheck in Icinga2
Konkret bedeutet das: Die Monitoring-Seite liest die vorhandenen Hiera-Daten aus den bestehenden Backup-Konfigurationen und erzeugt daraus automatisch Services wie Backup Age - <hostname>.
Was genau geprüft wird
Der Check fragt den S3-kompatiblen Storage ab und bewertet, wie alt der zuletzt geänderte Snapshot im jeweiligen Bucket ist.
Die Standardlogik ist bewusst klar:
- Warning nach 20 Stunden
- Critical nach 24 Stunden
Damit lässt sich sehr schnell erkennen, ob ein Backup zwar grundsätzlich konfiguriert ist, aber im Tagesbetrieb aus dem erwarteten Zeitfenster fällt.
Warum der erste Ansatz noch nicht gereicht hat
Wie so oft lag der Unterschied zwischen Konzept und belastbarem Betrieb im Detail.
Anfangs lag der Fokus auf einer allgemeinen Objektprüfung im Bucket. Das klingt logisch, ist bei Restic-Repositories aber nicht sauber genug, weil dort sehr viele Objekte unter data/ liegen. Wer einfach “das neueste Objekt” sucht, kann in großen Repositories in falsche oder unvollständige Ergebnisse laufen.
Deshalb wurde das Modul an zwei entscheidenden Punkten nachgeschärft:
1. Prüfung auf den richtigen Bereich eingeschränkt
Statt das gesamte Repository zu bewerten, prüft der Check gezielt den Prefix snapshots/. Genau dort liegen die Snapshot-Dateien mit dem relevanten Änderungszeitpunkt für den letzten Backup-Stand.
2. Pagination im Plugin ergänzt
Zusätzlich wurde das Plugin so erweitert, dass Objektlisten vollständig paginiert verarbeitet werden. Das ist wichtig, damit auch bei größeren Buckets zuverlässig alle relevanten Einträge berücksichtigt werden.
Erst diese beiden Punkte machen den Check in gewachsenen Umgebungen wirklich belastbar.
Automatische Zuordnung an den richtigen Backup-Server
Ein weiterer wichtiger Teil der Umsetzung war das Assignment in Icinga2.
Die Checks sollen nicht irgendwo laufen, sondern auf dem jeweiligen Backup-Server, der für den Client zuständig ist. Deshalb wurde das Pattern an die reale Backup-Server-Struktur angepasst:
- Zuordnung über
backup_serverdes Clients - Fallback auf
default_server, wenn kein eigener Wert gesetzt ist - Assignment direkt auf den jeweiligen Backup-Host
Damit bleibt die Ausführung logisch dort verankert, wo sie betrieblich hingehört.
Ausschlüsse ohne Sonderlogik
Wie bei jeder automatischen Ableitung gibt es auch hier Fälle, die bewusst nicht ins Monitoring sollen. Dafür wurde ein einfacher Exclude-Mechanismus ergänzt.
Mit einem Flag wie monitoring_exclude: true lässt sich ein einzelnes Repository sauber von der automatischen Service-Erzeugung ausnehmen, ohne das Grundmodell zu brechen.
Das ist im Alltag wichtig, weil sich Sonderfälle dann kontrolliert behandeln lassen, ohne wieder manuelle Ausnahmen in Templates oder Host-Objekten einzubauen.
Was sich daraus operativ verbessert
Der eigentliche Nutzen liegt nicht nur in einem weiteren Service in Icinga2, sondern in einem besseren Signal für den Betrieb.
Statt nur zu sehen, dass ein Backup-Stack existiert, wird jetzt direkt sichtbar:
- ob ein Repository aktuell beschrieben wurde
- welche Clients aus dem erwarteten Zeitfenster laufen
- an welchem Backup-Server die Prüfung ausgeführt wird
- welche Repositories bewusst ausgeschlossen wurden
Das reduziert Suchaufwand im Incident und macht Backup-Betrieb deutlich transparenter.
Fazit
Gutes Backup Monitoring beginnt nicht bei hübschen Dashboards, sondern bei der richtigen Frage: Ist im Zielsystem wirklich ein aktueller Stand angekommen? Genau dafür ist der neue Backup-Age-Check gedacht.
Durch die automatische Ableitung aus bestehender Backup-Konfiguration bleibt das Modell schlank, konsistent und gut wartbar. Und weil technische Randfälle wie Prefix-Auswahl, Pagination und Host-Zuordnung sauber berücksichtigt wurden, ist daraus kein Demo-Feature geworden, sondern ein brauchbarer Baustein für den realen Betrieb.
Wenn ihr eure Backup-Strecken transparenter machen wollt, helfen meist drei Dinge am meisten: saubere Repository-Struktur, verlässliche Monitoring-Signale und ein Betriebskonzept, das Restore und Aktualität gleichermaßen ernst nimmt. Für genau solche Setups unterstützen wir bei Backup für Unternehmen, Managed IT und stabilen Server-Infrastrukturen.