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.