Backup-Fehleralarme: Wissen, bevor Sie restoren müssen

Inhaltsverzeichnis

Die drei Arten, wie ein Backup scheitert
Schritt 1: Einen Kanal anlegen, der Ihre Aufmerksamkeit bekommt
Schritt 2: Fehler mit einem Wrapper-Skript abfangen
borg und borgmatic
Schritt 3: Das Backup abfangen, das nie lief
Schritt 4: Prüfen, ob das Backup aktuell und wiederherstellbar ist
Schritt 5: Nur klingeln, wenn es zählt
Häufige Fragen
Wie werde ich benachrichtigt, wenn ein Backup fehlschlägt?
Bei welchen restic-Exit-Codes sollte ich alarmieren?
Woran merke ich, dass ein Backup stillschweigend nicht mehr läuft?
Reicht ein erfolgreicher Exit-Code, um einem Backup zu vertrauen?
Kann ich einen Anruf statt einer E-Mail bekommen?
Fazit
Verwandte Artikel

Die meisten merken erst an dem Tag, an dem sie ihr Backup brauchen, dass es kaputt war. Der Job ist vor drei Wochen mit einem Fehler beendet worden, niemand hat das Log gelesen, und der neueste Snapshot ist älter als der Fehler, den Sie gerade rückgängig machen wollen.

Die Lösung ist nicht ein besseres Backup-Tool. Es geht darum, dass ein Backup-Problem noch in derselben Stunde bei einem Menschen ankommt, in der es auftritt. Dieser Leitfaden zeigt, wie das für restic und borg (und alles andere, was aus einer Shell läuft) funktioniert. Er deckt die drei Arten ab, auf die Backups tatsächlich scheitern, mit Skripten zum Kopieren. Der letzte Schritt schickt den Alarm über Echobell auf Ihr Telefon, sodass ein kaputtes Backup klingelt, statt in einem Postfach zu liegen.

Die drei Arten, wie ein Backup scheitert

Nur die erste zu überwachen ist der häufigste Fehler.

Es läuft und scheitert. Repository gesperrt, Platte voll, falsches Passwort, Netzausfall. Das Tool beendet sich mit einem Wert ungleich null.
Es läuft und gelingt nur halb. restic beendet sich mit Code 3, wenn ein Snapshot erstellt wurde, einige Dateien aber nicht lesbar waren. borg liefert bei Warnungen 1. Beides tut man leicht ab, und beides kann ein Berechtigungsproblem verbergen, das Ihr wichtigstes Verzeichnis stillschweigend überspringt.
Es läuft nie. Der Server war aus, der Timer deaktiviert, die Crontab überschrieben. Es gibt keinen Fehler, weil es keinen Prozess gibt. Dieser Ausfall wird Menschen zum Verhängnis.

Jeder Fall braucht einen anderen Detektor, also bauen wir alle drei.

Schritt 1: Einen Kanal anlegen, der Ihre Aufmerksamkeit bekommt

Legen Sie in Echobell einen Kanal namens backups an und setzen Sie den Benachrichtigungstyp für die wichtigen Jobs auf Anruf. Kopieren Sie die Webhook-URL:

https://hook.echobell.one/t/<channel-token>

Geben Sie ihm Templates, die auch im Halbschlaf Sinn ergeben, mit den Feldern, die wir unten senden:

Titel: Backup {{status}} auf {{host}}
Text: {{job}}: {{detail}}

Die Syntax steht in der Template-Referenz.

Schritt 2: Fehler mit einem Wrapper-Skript abfangen

Ein kleiner Wrapper macht aus Exit-Codes Alarme. Speichern Sie ihn als /usr/local/bin/backup-run:

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

HOOK="https://hook.echobell.one/t/<channel-token>"
JOB="nightly-restic"

alert() {
  curl -fsS -m 10 -X POST "$HOOK" \
    -H "Content-Type: application/json" \
    -d "{\"job\":\"$JOB\",\"host\":\"$(hostname)\",\"status\":\"$1\",\"detail\":\"$2\"}" || true
}

restic backup /srv /etc --exclude-caches
code=$?

case $code in
  0)  ;;                                   # Erfolg: ruhig bleiben
  3)  alert "incomplete" "Snapshot saved, but some files were unreadable" ;;
  11) alert "locked" "Repository is locked by another process" ;;
  12) alert "auth-failed" "Wrong repository password" ;;
  *)  alert "failed" "restic exited with code $code" ;;
esac

exit $code

Warum die Details wichtig sind:

set -e wird bewusst nicht verwendet, damit das Skript den Alarm auch nach einem restic-Fehler noch erreicht.
|| true am curl sorgt dafür, dass ein nicht erreichbarer Webhook nie den echten Exit-Code überdeckt.
-m 10 verhindert, dass ein hängender Netzwerkaufruf den nächsten geplanten Lauf blockiert.

Die oben verwendeten restic-Exit-Codes sind im Handbuch von restic dokumentiert: 0 Erfolg, 1 fataler Fehler, 3 Snapshot erstellt, aber einige Quelldateien nicht lesbar, 10 Repository existiert nicht, 11 Sperren fehlgeschlagen, 12 falsches Passwort. Prüfen Sie sie auf Ihrem eigenen Rechner gegen restic version, da Codes im Lauf der Zeit hinzugekommen sind.

borg und borgmatic

borg liefert 0 bei Erfolg, 1 bei Warnungen und 2 oder höher bei Fehlern. Eine Datei, die sich während des Backups ändert, erzeugt 1 – bei Log-Verzeichnissen ist das Routine. Üblich ist daher, nur ab 2 zu alarmieren und für 1 eine leise Benachrichtigung zu senden:

borg create --stats ::'{hostname}-{now}' /srv /etc
code=$?
if [ "$code" -ge 2 ]; then
  alert "failed" "borg exited with code $code"
elif [ "$code" -eq 1 ]; then
  alert "warning" "borg finished with warnings"
fi

Wenn Sie borgmatic verwenden, führt dessen on_error-Hook einen Befehl aus, sobald borgmatic selbst auf einen Fehler stößt – der natürliche Ort für dasselbe curl. Beachten Sie die Grenze, die die borgmatic-Dokumentation selbst nennt: Läuft borgmatic nie, feuert on_error nie. Das ist Ausfallart Nummer drei, und die braucht Schritt 3.

Schritt 3: Das Backup abfangen, das nie lief

Ein Wrapper kann nur über einen Lauf berichten, der stattgefunden hat. Um Stille zu erkennen, drehen Sie die Logik um: Das Backup meldet sich bei einem Monitor, wenn es gelingt, und der Monitor alarmiert Sie, wenn die Meldung zu spät kommt. Das nennt man Dead-Man's-Switch.

Healthchecks.io (gehostet oder selbst betrieben) macht genau das:

Legen Sie einen Check mit dem Zeitplan 0 3 * * * und einer Karenzzeit von ein bis zwei Stunden an.
Hängen Sie dessen Ping ans Ende Ihres Jobs, sodass er nur bei Erfolg feuert.
Fügen Sie in den Integrationen des Checks einen Webhook hinzu, der auf die URL Ihres Echobell-Kanals zeigt.

Der Ping steht am Ende des Wrappers:

# in backup-run direkt vor dem abschließenden `exit $code`; pingt nur bei Erfolg
if [ $code -eq 0 ]; then
  curl -fsS -m 10 --retry 3 -o /dev/null https://hc-ping.com/<your-uuid>
fi

Healthchecks unterstützt außerdem die Ping-Varianten /start und /fail und kann den Exit-Code in der URL entgegennehmen, sodass ein einzelner Check auch hängende Jobs erkennt. Das Ergebnis: Ein toter Server, ein deaktivierter Timer und eine gelöschte Crontab-Zeile führen alle zum selben Ergebnis – einem klingelnden Telefon. Das allgemeine Muster und weitere Monitore finden Sie unter Cron-Job-Fehleralarme.

Schritt 4: Prüfen, ob das Backup aktuell und wiederherstellbar ist

Ein Backup kann planmäßig laufen, mit 0 enden und trotzdem nutzlos sein, etwa wenn Sie ein leeres Verzeichnis sichern, weil ein Mount fehlgeschlagen ist. Ergänzen Sie in einem separaten täglichen Job zwei günstige Plausibilitätsprüfungen:

Snapshot-Alter. Alarmieren Sie, wenn der neueste Snapshot älter ist als erwartet:

latest=$(restic snapshots --latest 1 --json | jq -r '.[0].time')
age_h=$(( ( $(date +%s) - $(date -d "$latest" +%s) ) / 3600 ))
if [ "$age_h" -gt 30 ]; then
  alert "stale" "Newest snapshot is ${age_h}h old"
fi

Repository-Integrität. restic check prüft die Struktur des Repositorys. Führen Sie es wöchentlich aus; bei großen Repositorys prüft restic check --read-data-subset=5% eine Stichprobe der Daten, ohne alles zu lesen. Alarmieren Sie bei einem Exit-Code ungleich null.

Keines von beiden ersetzt einen echten Test-Restore. Stellen Sie einmal pro Quartal eine Datei, die Sie überprüfen können, in ein Testverzeichnis wieder her. Das ist der einzige Test, der beweist, dass das Backup funktioniert.

Schritt 5: Nur klingeln, wenn es zählt

Wenn jede Warnung Sie anruft, schalten Sie den Kanal stumm – und dann klingelt er nicht bei dem einen, der zählt. Trennen Sie die Stufen auf einem Kanal mit den Echobell-Bedingungen:

status == "failed" || status == "stale" || status == "auth-failed"

Senden Sie incomplete und warning an einen zweiten Kanal vom Typ Zeitkritisch oder Normal, sodass sie auf dem Sperrbildschirm erscheinen, ohne zu klingeln. Ergänzen Sie ein Zeitfenster, wenn Ausfälle tagsüber leise bleiben sollen – mit den UTC-Variablen aus der Bedingungsreferenz.

Häufige Fragen

Wie werde ich benachrichtigt, wenn ein Backup fehlschlägt?

Wrappen Sie den Backup-Befehl, lesen Sie seinen Exit-Code und senden Sie bei jedem Code ungleich null einen Webhook. Ergänzen Sie einen Dead-Man's-Switch wie Healthchecks.io, damit Sie auch von Läufen erfahren, die nie gestartet sind.

Bei welchen restic-Exit-Codes sollte ich alarmieren?

Alarmieren Sie laut bei 1, 10, 11 und 12, die einen echten Fehler bedeuten. Behandeln Sie 3 (Snapshot erstellt, aber einige Dateien nicht lesbar) als Warnung, der Sie nachgehen sollten, da sie ein Berechtigungsproblem verbergen kann.

Woran merke ich, dass ein Backup stillschweigend nicht mehr läuft?

Nutzen Sie einen Heartbeat: Der Job meldet sich bei Erfolg bei einem Monitor, und der Monitor alarmiert, wenn die Meldung zu spät kommt. Ein Fehler-Hook kann das nicht erkennen, weil nichts läuft, das den Fehler auslösen könnte.

Reicht ein erfolgreicher Exit-Code, um einem Backup zu vertrauen?

Nein. Er bedeutet nur, dass das Tool fertig geworden ist – nicht, dass die Daten vollständig oder wiederherstellbar sind. Prüfen Sie das Snapshot-Alter, führen Sie regelmäßig Integritätsprüfungen durch und testen Sie eine Wiederherstellung.

Kann ich einen Anruf statt einer E-Mail bekommen?

Ja. E-Mails übersieht man leicht. Ein Anrufkanal in Echobell verhält sich wie ein eingehender Anruf und kommt durch den iOS-Fokus, sodass ein fehlgeschlagenes Backup um 03:00 Uhr bemerkt wird.

Fazit

Drei Detektoren decken die drei Fehlerarten ab: ein Exit-Code-Wrapper für Läufe, die scheitern, eine Aktualitätsprüfung für Läufe, die nutzlos gelingen, und ein Heartbeat für Läufe, die nie stattfinden. Leiten Sie sie an einen Anrufkanal, halten Sie Warnungen auf einem leiseren – und aus einem kaputten Backup wird eine Fünf-Minuten-Reparatur statt eines verlorenen Wochenendes.

Echobell für iPhone laden oder bei Google Play holen, den Kanal backups anlegen und den Wrapper einmal mit absichtlich falschem Passwort laufen lassen, um ihn klingeln zu hören.