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.

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.

Die fertige Lösung: ein Wächter ohne fremden Dienst

Der Aufruf oben setzt einen Überwachungsdienst voraus. Wer keinen betreiben oder mieten will, braucht etwas, das dieselbe Aufgabe lokal erledigt – und dabei die Regel einhält, um die es in diesem Artikel eigentlich geht: melden nur, wenn es etwas zu tun gibt.

Genau dafür ist dieses Skript gebaut: backup-waechter.sh – eine einzelne Bash-Datei, ohne Abhängigkeiten außer den Standardwerkzeugen und einem Mailversand.

Wann es schweigt und wann es meldet

Das ist der ganze Entwurf:

Ereignis	Mail?
Lauf war erfolgreich	nein
Lauf schlägt erstmals fehl	ja
Lauf schlägt weiter fehl, stündliche Prüfung	nein
Störung besteht seit 24 Stunden	ja, eine Erinnerung
Job meldet sich gar nicht mehr	ja
Störung ist behoben	ja, Entwarnung
Übertragene Menge weicht um ein Vielfaches ab	ja
Montagmorgen, alles in Ordnung	ja, eine Übersicht

Die dritte Zeile ist der Unterschied zwischen einem Wächter und einem Störenfried. Ein stündlicher Prüftimer und eine Störung, die drei Tage dauert, ergeben ohne diese Regel 72 Mails – und damit einen Postfachfilter statt einer Reaktion.

Die letzte Zeile ist die, die man beim ersten Lesen streichen möchte, und die man braucht. Ohne sie ist Schweigen zweideutig: Es kann „alles in Ordnung“ heißen oder „die Überwachung läuft nicht mehr“. Genau diese Zweideutigkeit ist der Fehler, gegen den das ganze Werkzeug gebaut ist; sie darf nicht an seiner eigenen Wurzel wieder auftauchen.

Einrichtung

install -m 0755 backup-waechter.sh /usr/local/sbin/backup-waechter
install -d -m 0750 /var/lib/backup-waechter

Konfiguration in /etc/backup-waechter.conf, alle Werte optional:

EMPFAENGER="technik@example.org"
WIEDERHOLUNG_STUNDEN=24     # 0 = nur einmal melden
WOCHENBERICHT_TAG=1         # 1 = Montag, 0 = keine Wochenuebersicht
MENGE_FAKTOR=5              # ab welchem Vielfachen eine Menge auffaellt

Im Sicherungsskript den bisherigen Aufruf umschließen:

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

backup-waechter melden --job daten --erwartung 24 -- \
    restic backup /daten

--erwartung 24 heißt: Dieser Job soll sich alle 24 Stunden melden. Bleibt er länger aus als Erwartung plus Karenz (Vorgabe sechs Stunden), schlägt der Wächter Alarm – auch dann, wenn die ganze Maschine aus ist und niemand einen Fehler gesehen hat. Das ist die stille Fehlerklasse von oben.

Für Jobs, die sich nicht umschließen lassen – etwa ein PBS-Auftrag, der die Meldung per Hook absetzt –, gibt es die zweite Form:

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

ergebnis=0
pbs-auftrag || ergebnis=$?      # NICHT nur `pbs-auftrag` – siehe unten

backup-waechter melden --job pbs --erwartung 24 --ergebnis "$ergebnis"

Die vierte Zeile ist der Grund, warum hier ein Skript und kein Einzeiler steht. Der naheliegende Aufruf – Auftrag ausführen, danach --ergebnis "$?" – funktioniert nicht: set -e beendet das Skript beim ersten Fehlschlag, also genau dann, wenn es etwas zu melden gäbe. Die Meldezeile wird nie erreicht, der Wächter erfährt vom Fehler nichts und meldet Stunden später bestenfalls „überfällig“. || ergebnis=$? fängt den Rückgabewert ab, ohne den Abbruch auszulösen.

Das ist keine Eigenheit dieses Werkzeugs, sondern die übliche Falle bei jeder Fehlerbehandlung unter set -e: Wer den Rückgabewert eines Befehls auswerten will, muss ihn im selben Ausdruck abfangen.

--menge <bytes> lässt sich anhängen, wenn der Auftrag die übertragene Menge ausgibt. Der Wert muss vorher in einer Variablen stehen – unter set -u beendet ein nicht gesetzter Name das Skript. Er füttert die Mengenprüfung aus der Tabelle weiter oben. Verglichen wird gegen den Median der letzten Läufe, nicht gegen den Durchschnitt: Ein einzelner Ausreißer soll den Vergleichswert nicht verschieben, sonst gewöhnt sich die Überwachung an den Ausreißer.

Der Prüfteil gehört in einen eigenen Timer, stündlich:

# /etc/systemd/system/backup-waechter.timer
[Unit]
Description=Sicherungen auf ausbleibende Laeufe pruefen

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/backup-waechter.service
[Unit]
Description=Sicherungen auf ausbleibende Laeufe pruefen

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/backup-waechter pruefen

Vor der Übernahme ausprobieren

backup-waechter pruefen --probelauf

Schreibt die Mail auf die Standardausgabe, statt sie zu verschicken, und ändert nichts am gespeicherten Zustand. Damit lässt sich ansehen, was ankommen würde, bevor es jemand im Postfach hat.

Für die monatliche Sichtkontrolle weiter unten:

backup-waechter zeigen

Die Karenzzeit bestimmen

Die einzige Einstellung, die man nicht raten sollte – und die einzige, für die in Anleitungen üblicherweise eine Zahl ohne Begründung steht. Auch die sechs Stunden Vorgabe im Skript sind eine Setzung, keine Erkenntnis.

Zu kurz gewählt meldet der Wächter Fehlalarme, sobald ein Lauf einmal länger dauert. Nach drei Fehlalarmen ist die Überwachung abgeschaltet – der Weg, auf dem die meisten Monitorings sterben. Zu lang gewählt bleibt ein echter Ausfall entsprechend lange unbemerkt.

Der Wert lässt sich ableiten, statt ihn zu wählen. Die Karenz muss genau drei Dinge überdecken:

Größe	Woher
Längste normale Laufzeit	misst der Wächter selbst mit
RandomizedDelaySec des Timers	steht in deiner Timer-Unit
Reserve für einen einmaligen Nachholvorgang	eine Stunde genügt meist

Die erste Größe zeigt die Übersicht in der Spalte MAX LAUF:

$ backup-waechter zeigen
JOB              LAGE         LETZTER ERFOLG     MAX LAUF   KARENZ   ANMERKUNG
daten            ok           06.08.2026 02:41   38 min     6 h
pbs              ok           06.08.2026 03:12   -          6 h

Daraus die Rechnung: längste beobachtete Laufzeit + RandomizedDelaySec + eine Stunde, aufgerundet auf volle Stunden. Bei 38 Minuten Spitzenlaufzeit und 15 Minuten Zufallsverzögerung wären das rund zwei Stunden – die Vorgabe von sechs ist dann großzügig, aber nicht falsch.

Zwei Dinge verschieben den Wert in der Praxis:

Warte einige Wochen, bevor du enger stellst. Die Spitzenlaufzeit der ersten Tage ist nicht die des Monats. Ein Lauf nach einem größeren Zuwachs oder nach einer Aufräumaktion dauert deutlich länger als der Durchschnitt, und genau der darf keinen Fehlalarm auslösen.

Bei Persistent=true gehört die Ausschaltzeit dazu. Wird die Maschine nachts heruntergefahren, holt systemd den Lauf beim nächsten Start nach – bis dahin vergeht Zeit, die der Wächter sonst als Ausfall wertet. Bei einem Gerät, das über das Wochenende aus ist, ist die Karenz allerdings der falsche Hebel: Dann gehört --erwartung hochgesetzt, sonst deckt die Karenz einen echten Ausfall mit ab.

Die Spalte MAX LAUF bleibt leer, solange ein Job seine Ergebnisse mit --ergebnis einträgt, statt sich umschließen zu lassen – dann kennt der Wächter die Laufzeit nicht.

Was es bewusst nicht tut

Es ersetzt keinen zweiten Kanal. Wenn der Mailversand Teil des Problems ist, hilft eine Mail nichts. Dafür braucht es einen Weg, der nicht über denselben Server läuft.

Es überwacht sich nicht selbst. Läuft der Timer nicht mehr, bleibt die Wochenübersicht aus – das ist die Stelle, an der der Mensch dran ist, und der Grund, warum diese eine Mail nicht wegoptimiert gehört.

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.

Die Falle im Backup-Job

Auf der Seite von Proxmox VE sitzt die entsprechende Einstellung im Backup-Job unter Notifications:

Die Voreinstellung Use global notification settings klingt harmlos und ist einer der häufigsten Gründe dafür, dass niemand etwas erfährt: Sie verweist auf die Konfiguration unter Datacenter → Notifications. Dort steht in einer frischen Installation ein Ziel, das an den root-Benutzer des Knotens zustellt – also an ein lokales Postfach, das üblicherweise niemand liest, und das obendrein nur dann irgendwo ankommt, wenn der Knoten überhaupt Mail versenden kann.

Die Einstellung ist damit nicht falsch, sondern unvollständig. Richtig wird sie erst, wenn unter Datacenter → Notifications ein Ziel eingetragen ist, das tatsächlich jemanden erreicht. Der zweite Punkt, Use sendmail (legacy), ist der alte Weg mit einem Empfänger direkt am Job; er funktioniert, umgeht aber die zentrale Verwaltung und wird bei zehn Jobs zur Fleißaufgabe.

In beiden Fällen gilt die Einschränkung von oben: Was hier eingestellt wird, meldet sich, wenn der Job läuft. Läuft er gar nicht, schweigt es. Dagegen hilft nur der Totmannschalter.

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