From f466e87f7a4884d3bd0478072b27f9985ab34f89 Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Fri, 21 Aug 2026 12:00:00 +0000 Subject: [PATCH] docs: the media probe runs monthly, and its failure is provably visible restore-drill-media, on the 4th at 05:20, an hour after the database probe. The name is the alerting: BackupJobFailed already matches restore-drill.*, so a failure needs no new rule and reaches the maintenance room through the single alertmanager route. Every link is measured rather than assumed. A control run with a deliberately damaged file reported one mismatch and failed the job. The job name was checked against the rule's regex. The route was read from the config. And delivery works today: seven notifications sent, none failed, alertmanager up. The probe re-proves its own comparison on every run: after passing, it alters one shared file by a byte and fails with "this probe proves nothing" if the comparison stays quiet. That a comparison has only ever said "equal" is a guess, and running monthly does not change it. Silence is covered too - the stale and missing alarms now match the prefix and name which probe is affected - but those two rule changes sit in threadnet-operating and are not live: the operating stack does not pull by itself, and Prometheus still serves the old expressions, measured through its rules API. The failure alarm is unaffected and already armed. Written down as open rather than reported as done. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM --- ...estore-ist-nie-geprobt-sicherungen-sind.md | 43 +++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md b/docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md index d52af94..202d4ba 100644 --- a/docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md +++ b/docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md @@ -391,3 +391,46 @@ dass das Zurückschreiben unter Last funktioniert. Das steht so auch in `restore **Vorschlag, nicht umgesetzt:** Diese Probe ließe sich wie `restore-drill` monatlich fahren. Sie ist gefahrlos (lesend, `emptyDir`), dauert wenige Minuten und wäre die einzige Prüfung, die den Medienpfad überhaupt beobachtet. Entscheidung sorb. + +## Nachtrag 2026-08-21 (zweiter Teil) — Medien-Probe automatisiert (Auftrag sorb) + +Der Vorschlag von oben ist umgesetzt: **`restore-drill-media`**, monatlich am 4. um 05:20, +eine Stunde nach der Datenbank-Probe. Eigener CronJob statt Anbau — die Datenbank-Probe +braucht eine Wegwerf-Postgres, diese das Produktions-PVC (lesend); zwei Rechte- und +Fehlerbilder in einem Job machen die Fehlersuche im Ernstfall schwerer. + +### Fehlschlag ist im Wartungsraum sichtbar — belegt, nicht angenommen + +| Glied | Beleg | +|---|---| +| Echter Datenschaden lässt den Job scheitern | Kontroll-Lauf mit absichtlich verfälschter Datei: `davon abweichend: 1` → `FEHLER` → `failed=1` | +| Der Job fällt unter die bestehende Alarmregel | `BackupJobFailed` matcht `restore-drill.*`; `restore-drill-media-…` geprüft | +| Es gibt genau eine Alertmanager-Route | `receiver: matrix` → wartung-Raum, keine Aufteilung nach `room` mehr | +| Die Zustellung funktioniert heute | `alertmanager_notifications_total = 7`, `…_failed_total = 0`, `up{job="operating_alertmanager"} = 1` | + +**Der Name ist die Alarmierung.** `restore-drill-media` fällt ohne neue Regel unter +`BackupJobFailed` — deshalb heißt er so und nicht `media-restore-drill`. + +### Die Probe beweist bei jedem Lauf ihre eigene Vergleichslogik + +Nach dem bestandenen Abgleich verfälscht der Job **eine gemeinsame Datei um ein Byte** und +verlangt, dass der Vergleich es meldet. Tut er es nicht, scheitert der Lauf mit *„diese +Probe beweist nichts"*. Ein Abgleich, der nur je „gleich" gesagt hat, ist eine Vermutung — +und das bleibt wahr, wenn er monatlich statt einmalig läuft. + +Erstlauf des ausgerollten CronJobs: `318 Dateien zurueckgespielt, alle gemeinsamen +byte-gleich, Vergleich gegengeprueft`. + +### Auch die Stille ist abgedeckt — aber noch nicht scharf + +`RestoreDrillStale` matcht jetzt `restore-drill.*` statt eines festen Namens und nennt die +betroffene Probe in der Meldung; mit zwei Proben sagt „die Restore-Probe lief nicht" sonst +nicht, welche. `BackupCronJobMissing` kennt den neuen CronJob, weil eine verschwundene +Serie in Prometheus kein Alarm ist, sondern Stille. + +⚠️ **Offen: Diese beiden Regeländerungen liegen in `threadnet-operating` (`2eec485`), +laufen aber noch nicht.** Der operating-Stack zieht seine Konfiguration nicht automatisch; +Prometheus führt weiterhin die alte Fassung — nachgemessen über die Rules-API. **Der +Fehlschlag-Alarm ist davon nicht betroffen und schon jetzt scharf**, nur die zwei +Stille-Alarme brauchen ein `git pull` und einen Reload auf dem Host. Seit die Configs als +Verzeichnis gemountet sind (#0083), genügt dafür ein Reload ohne Neuanlage.