Thore CimbalandClaude Fable 5
c23bb54a92
Gate 4, slice 4: 26 open management issues imported from live git.lab (read-only, descriptions included as authorized; GitLab iid = file id, labels/milestone/priority/due/host/area mapped into frontmatter, the import aborts instead of inventing a missing milestone or priority). Two new issues close the F-004 gap where work was really still open (0033 OVERMIND-01, 0034 CFGMON-11 incl. the plaintext npm-token rotation); CFGMON-12/13 already route to verified git.lab issues, MATRIX-05 is done and needs none (agreed with sorb). The three wiki task blocks now reference their issues, roadmap.md hands all counts to the generated STATUS.md and states M1-M5 per ADR-0010 (closing F-001 in the canonical prose), pruefe_prosa joins the CI validate job, and the import protocol under docs/sources/migration/ records every intervention into imported text. Verified: validate 0/0 over 29 issue files, gen_status --check current (distribution line M1 9 - M2 17 - M4 2 plus per-issue milestone and priority), pruefe_prosa 0 errors with clones and 0 errors/15 unchecked citations in offline CI mode, drift check green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2.7 KiB
type, id, status, created, milestone, priority, area, gitlab_iid, related
| type | id | status | created | milestone | priority | area | gitlab_iid | related |
|---|---|---|---|---|---|---|---|---|
| issue | 0030 | open | 2026-08-06 | M1 | medium | security | 30 |
Der Restore ist nie geprobt — Sicherungen sind bisher eine Vermutung
Import aus management#30 (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).
Es wird gesichert: jeden Sonntag, alle Dienste, drei Versionen vorgehalten, GitLab auf Overmind mit Datenbank und Volumes nach MinIO auf dem DSM. Das ist mehr, als die meisten haben.
Was fehlt, ist der Beweis, dass sich daraus etwas wiederherstellen lässt. Es gibt kein dokumentiertes Verfahren und keinen je durchgespielten Versuch. Eine Suche über docs/ und verfahren/ findet nur Erwähnungen in install.md — keine Anleitung, keine Protokolle.
Warum das der wichtigste der offenen Punkte ist
Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung. Die typischen Fehler zeigen sich ausschließlich beim Zurückspielen und nie beim Sichern:
- die Datenbank ist gesichert, aber ohne das Volume mit den Uploads ist sie wertlos
- der Dump ist da, aber der Verschlüsselungsschlüssel lag nur auf dem Host, der weg ist
- es liegen drei Versionen, aber alle drei sind seit Wochen leer, weil ein Pfad umgezogen ist und keiner es gemerkt hat
- niemand weiß, in welcher Reihenfolge die Dienste hochkommen müssen
Der letzte Punkt ist hier besonders relevant: Der SOPS-age-Schlüssel entschlüsselt alle Secrets im Cluster. Wenn der nur an einer Stelle liegt, ist die Frage nicht, ob die Sicherung funktioniert, sondern ob sie überhaupt etwas nützt.
Was zu tun ist
- Zuerst das Billigste: stichprobenartig in die aktuellen Sicherungen hineinschauen. Sind sie plausibel groß? Enthalten sie, was sie sollen? Das findet stille Ausfälle sofort.
- Ein echtes Wiederherstellungsverfahren schreiben — als Ablauf, nicht als Prosa: welcher Dienst zuerst, woher der SOPS-Schlüssel, woher der kubeconfig.
- Einmal wirklich durchspielen, gegen eine Wegwerf-Umgebung, nicht gegen die Produktion. Was dabei fehlt, ist das Ergebnis.
- Ergebnis als Verfahren in
verfahren/ablegen und danach in bekanntem Abstand wiederholen.
⚠️ Bewusst nicht vorschlagen: die Sicherung erweitern, bevor die vorhandene geprüft ist. Mehr zu sichern, ohne zu wissen, ob das Vorhandene trägt, verschiebt das Problem nur.
Grenzen dieses Issues
Ich kenne den Sicherungsaufbau nur aus deiner Beschreibung und einem Screenshot, nicht aus eigener Anschauung. Der erste Schritt ist deshalb Bestandsaufnahme, nicht Bewertung.
Aufgenommen am 2026-08-06 bei einer Bestandsaufnahme der Sicherheitslage.