Backup-Monitoring: Merken, wenn die Sicherung ausfällt

Ein Backup, das seit vier Monaten nicht mehr läuft, ist gefährlicher als gar keines. Ohne Backup weißt du, woran du bist. Mit einem stillschweigend ausgefallenen Backup triffst du Entscheidungen auf Basis einer Sicherheit, die es nicht gibt.

Das ist keine hypothetische Konstruktion, sondern der Normalfall: Ein Zertifikat läuft ab, eine Platte ist voll, ein Zugangstoken wird ungültig, ein Update ändert einen Pfadnamen. Der Job scheitert. Niemand merkt es, weil niemand hinschaut – und weil Erfolgsmeldungen ausbleiben, ohne dass das auffällt.

Die zwei Fehlerklassen

Für die Überwachung entscheidend ist die Unterscheidung:

Der Job läuft und scheitert. Es gibt einen Rückgabewert, ein Log, oft eine Fehlermeldung. Vergleichsweise einfach zu erkennen.

Der Job läuft gar nicht. Timer deaktiviert, Maschine aus, Cron-Eintrag beim Umzug verloren gegangen. Hier passiert nichts – und genau das ist das Problem. Eine Überwachung, die nur auf Fehlermeldungen reagiert, ist gegen diese Klasse blind.

Deshalb reicht „ich bekomme eine Mail, wenn etwas schiefgeht“ nicht aus. Es braucht die umgekehrte Logik.

Der Totmannschalter

Das Prinzip: Der Backup-Job meldet seinen Erfolg aktiv. Bleibt die Meldung aus, schlägt die Überwachung Alarm.

Backup laeuft durch  ->  sendet "ich lebe" an den Ueberwachungsdienst
                              |
Ueberwachungsdienst erwartet die Meldung alle 24h (+ Karenzzeit)
                              |
Meldung bleibt aus   ->  ALARM

Der Unterschied ist fundamental: Nicht der Fehler löst den Alarm aus, sondern das Ausbleiben des Erfolgs. Damit werden beide Fehlerklassen abgedeckt – auch die, bei der die ganze Maschine aus ist.

Umsetzen lässt sich das mit jedem Überwachungssystem, das passive Prüfungen oder Push-Monitore kennt. Der Kern ist immer derselbe: ein HTTP-Aufruf am Ende des erfolgreichen Laufs.

#!/usr/bin/env bash
set -euo pipefail

restic backup /daten --verbose

# nur bei Erfolg erreicht, weil set -e vorher abbricht
curl -fsS --retry 3 "https://<ueberwachung>/ping/<kennung>"

Wichtig ist set -euo pipefail in der ersten Zeile. Ohne -e läuft das Skript nach einem Fehler weiter und meldet fröhlich Erfolg – der klassische Fall eines Monitorings, das schlimmer ist als keines.

Was überwacht gehört

Erfolg allein ist zu wenig. Fünf Größen, mit klarer Priorität:

Was	Warum	Alarm bei
Alter der letzten erfolgreichen Sicherung	die wichtigste Einzelgröße	älter als Intervall + Karenz
Freier Speicher am Ziel	volle Platte = stiller Ausfall	unter 15–20 %
Ergebnis der Verifikation	erkennt stille Beschädigung	jeder Fehler
Übertragene Datenmenge pro Lauf	Ausreißer sind ein Warnsignal	Abweichung um ein Vielfaches
Laufzeit	schleichende Verschlechterung	deutlich über dem Normalwert

Die vierte Zeile verdient eine Erklärung, weil sie meist fehlt: Verschlüsselte Dateien lassen sich nicht deduplizieren. Wenn ein Sicherungslauf plötzlich ein Vielfaches der üblichen Menge überträgt, kann das ein legitimer Grund haben – oder es ist das erste sichtbare Zeichen eines Ransomware-Befalls, siehe Ransomware-sichere Backups. In beiden Fällen willst du es wissen.

Umgekehrt gilt dasselbe: Eine plötzlich sehr kleine Übertragung deutet darauf hin, dass ein Verzeichnis nicht mehr erfasst wird.

Umsetzung: Proxmox Backup Server

PBS bringt eine eigene Benachrichtigungsverwaltung mit. Einzurichten sind:

Ein Benachrichtigungsziel. SMTP oder ein Webhook auf einen Dienst deiner Wahl. Für kritische Meldungen ist ein zweiter Kanal sinnvoll, der nicht E-Mail ist – wenn der Mailserver Teil des Problems ist, hilft eine Mail wenig.

Sinnvolle Auslöser. Die Voreinstellung meldet oft jeden Lauf. Das führt nach zwei Wochen dazu, dass die Meldungen ungelesen in einen Ordner sortiert werden. Besser: Fehler und Warnungen einzeln melden, Erfolge nur als Tagesübersicht.

Verify-Jobs einbeziehen. Ein fehlgeschlagener Verify-Lauf ist ein Alarm erster Ordnung – er bedeutet, dass gespeicherte Daten nicht mehr lesbar sind.

Zusätzlich: PBS selbst überwachen. Ein Backup-Server, dessen Platte voll ist oder der nicht läuft, meldet sich nicht von selbst. Der Totmannschalter gehört auch hierher.

Einrichtung des Servers: Proxmox Backup Server einrichten.

Umsetzung: restic oder Borg per systemd

Wer über Skripte sichert, nutzt am besten systemd statt Cron – wegen der besseren Fehlerbehandlung.

Service-Unit (/etc/systemd/system/backup.service):

[Unit]
Description=Taegliche Datensicherung

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/backup.sh
OnFailure=backup-alarm@%n.service

Timer-Unit (/etc/systemd/system/backup.timer):

[Unit]
Description=Taegliche Datensicherung

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

Zwei Optionen, die man kennen sollte:

Persistent=true holt einen verpassten Lauf nach, wenn die Maschine zum geplanten Zeitpunkt aus war. Ohne diese Zeile fällt der Lauf ersatzlos aus.

RandomizedDelaySec verteilt die Startzeit. Sinnvoll, sobald mehrere Systeme dasselbe Ziel beschreiben.

Die über OnFailure referenzierte Unit ist ein kleiner Dienst, der die Meldung verschickt – der Vorteil gegenüber einer Fehlerbehandlung im Skript: Sie greift auch, wenn das Skript abstürzt, bevor es dazu kommt.

Prüfen, ob der Timer wirklich läuft:

systemctl list-timers backup.timer
journalctl -u backup.service --since "7 days ago"

Der erste Befehl gehört in die monatliche Routine. Ein Timer, den man nach einem Update zu aktivieren vergessen hat, ist eine der häufigsten Ursachen für die stille Fehlerklasse.

Alarmmüdigkeit vermeiden

Ein Monitoring, das täglich meldet, wird nach drei Wochen ignoriert. Damit ist es wirkungslos – und man hat sich zusätzlich in Sicherheit gewiegt.

Drei Regeln, die sich bewähren:

Erfolg meldet sich nicht einzeln. Eine Wochenübersicht genügt. Der Totmannschalter übernimmt die Aufgabe, das Ausbleiben zu bemerken.

Fehler unterscheiden sich von Warnungen. Ein fehlgeschlagener Lauf ist etwas anderes als eine Platte bei 80 %. Verschiedene Dringlichkeit, verschiedene Kanäle, verschiedene Reaktionszeit.

Jede Meldung ist mit einer Handlung verknüpft. Wenn auf eine Meldung nichts folgt, gehört sie abgeschaltet. Meldungen ohne Handlung sind der eigentliche Grund für Alarmmüdigkeit.

Die monatliche Kontrolle

Automatisches Monitoring ersetzt nicht den Blick. Einmal im Monat, zehn Minuten:

• Wann war die letzte erfolgreiche Sicherung jedes Systems?
• Ist jedes System, das gesichert werden soll, auch tatsächlich in der Liste?
• Freier Speicher am Ziel – reicht er noch drei Monate?
• Ergebnisse der letzten Verifikationsläufe
• Laufen die Timer alle noch?
• Ist der Totmannschalter selbst noch aktiv?

Der zweite Punkt ist der, der am meisten findet. Neue Systeme werden angelegt und nicht in die Sicherung aufgenommen – kein Fehler meldet sich, weil nichts fehlschlägt. Es existiert schlicht nicht.

Der letzte Punkt ist der, den alle vergessen: Wer überwacht die Überwachung? Wenn der Überwachungsdienst selbst ausfällt, bleibt der Alarm ebenfalls aus. Ein zweiter, unabhängiger Kanal für die wichtigste Prüfung ist keine Übertreibung.

Checkliste

• Erfolg wird aktiv gemeldet, nicht nur Fehler
• Ein Totmannschalter erkennt ausbleibende Läufe
• Das Alter der letzten erfolgreichen Sicherung ist jederzeit ablesbar
• Freier Speicher am Ziel wird überwacht
• Verifikationsergebnisse lösen Alarm aus
• Ungewöhnliche Übertragungsmengen fallen auf
• Skripte brechen bei Fehlern ab (set -euo pipefail)
• Es gibt einen zweiten Kanal, der nicht E-Mail ist
• Erfolgsmeldungen sind gebündelt, nicht einzeln
• Die Überwachung selbst wird überwacht
• Eine monatliche Sichtkontrolle steht im Kalender

Weiter im Cluster

• 3-2-1-Backup-Strategie – der Überbau
• Proxmox Backup Server einrichten – Benachrichtigungen in PBS
• Restore testen – Monitoring beweist nicht, dass ein Restore gelingt
• Ransomware-sichere Backups – Datenmenge als Frühwarnsignal
• Typische Backup-Fehler