Thore CimbalandClaude Opus 4.8
87aab7948f
sorb's call: Gitea on rohana is a push mirror of the canonical git.lab, so a nightly gitea dump would back up a copy — effort not justified, cron stays off. Documented the one non-mirror asset for the record: the container registry holds four images the cluster pulls (incl. threadnet-web and the backup image itself), which is rebuild time rather than data loss and is covered by #0022/#0033. For #0030, sorb confirms the age key is also in the password vault, dissolving the circular dependency found earlier. Noted that the vault is now part of the restore path and must lead the procedure. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
4.9 KiB
type, id, status, created, milestone, priority, host, area, gitlab_iid, related
| type | id | status | created | milestone | priority | host | area | gitlab_iid | related |
|---|---|---|---|---|---|---|---|---|---|
| issue | 0010 | rejected | 2026-08-01 | M1 | medium | cfgmon | security | 10 |
CFGMON-09: Gitea-Backups off-host (Borg/Storage Box) — Backup-Cron ist DEAKTIVIERT
Import aus management#10 (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).
⚠️ Seit 2026-07-30 laufen KEINE Gitea-Backups — der nächtliche Cron ist
auskommentiert (Crontab rantanplan), letzter Stand
/opt/backup/gitea-dump-2026-07-30.tar.gz. Beim Erledigen/Verwerfen dieses Punkts
den Cron wieder aktivieren.
Plan: eigenes Borg-Repo auf einer Hetzner Storage Box (spricht Borg nativ über
SSH Port 23). Dump unkomprimiert an Borg geben (gzip im Script entfällt, sonst
greift Dedup nicht); Retention via borg prune (7d/4w/6m); optional Sub-Account.
Kontext: Platte 73 % voll, Script rotiert auf genau einen Stand, Off-host-Kopie
fehlt komplett — bei Verlust des Hosts wäre Gitea (inkl. Mirror-Kopien) weg.
Voraussetzungen (User): Storage-Box/Sub-Account im Robot anlegen; Host hat keinen SSH-Key → generieren und Public Key in der Storage Box hinterlegen.
Quelle: hosts/cfgmon.md
Übernommen aus dem Backlogs-Markdown beim Framework-Umbau 2026-08-01 (voller Wortlaut: Git-Historie der Datei).
In Arbeit 2026-08-14 — Muster existiert bereits (Aufwand deutlich kleiner als geplant)
Bei der Bestandsaufnahme für #0030 zeigte sich: Borg auf Hetzner Storage Box läuft im Matrix-Cluster bereits produktiv — der für dieses Issue geplante Aufbau muss also nicht erfunden, sondern nur auf Gitea übertragen werden.
Vorhandenes Muster (erprobt, nächtlich, verifiziert):
- Storage Box
u641795@u641795.your-storagebox.de:23, drei getrennte Repos (/./synapse-backup,/./authentik-backup,/./wikijs-backup). - Image
rohana.axion1337.de/sorb/axion-backup:v2; Retentionborg prune7d/4w/6m. - Credentials (Borg-Passphrase + SSH-Key) als SOPS-Secret, per Env in den Job.
Konsequenz für Gitea: kein neuer Storage-Box-Vertrag nötig — ein zusätzliches Repo
/./gitea-backup auf derselben Box (oder ein Sub-Account) genügt. Der Host braucht weiterhin
einen eigenen SSH-Key (CFGMON ist nicht der Cluster), dessen Public Key in der Storage Box
hinterlegt wird. Wie im Issue vorgesehen: Dump unkomprimiert an Borg geben (gzip aus
backup/gitea-backup.sh entfernen), sonst greift die Deduplizierung nicht.
⚠️ Unverändert akut: Der nächtliche Cron auf CFGMON ist seit 2026-07-30 auskommentiert —
seit über zwei Wochen läuft kein Gitea-Backup, der letzte Stand ist
/opt/backup/gitea-dump-2026-07-30.tar.gz. Das ist unabhängig von der Borg-Umstellung sofort
behebbar (Cron wieder einkommentieren) und sollte nicht auf das Off-host-Projekt warten.
⚠️ Vorrang laut #0030: Bevor Backups erweitert werden, muss die kalte Kopie des age-Schlüssels stehen (dort dokumentierte Zirkelabhängigkeit) — sonst wächst nur die Menge potenziell unlesbarer Sicherungen.
Offen (nur mit Host-Zugang, kein SSH zu CFGMON von hier): Cron reaktivieren; SSH-Key auf
CFGMON erzeugen + in der Storage Box hinterlegen; gitea-backup.sh auf Borg umstellen.
Verworfen 2026-08-14 — Gitea braucht kein eigenes Backup (Entscheidung sorb)
Begründung: Gitea auf rohana ist Push-Mirror, nicht Quelle. Kanonisch ist git.lab
(ADR-0001); alle gespiegelten Repos lassen sich nach einem Totalverlust schlicht neu
befüllen. Die Issues liegen seit der Migration ohnehin auf git.lab, der Gitea-Tracker ist
leer. Ein nächtlicher gitea dump sichert damit im Wesentlichen eine Kopie — der Aufwand
(Borg-Repo, Host-SSH-Key, Script-Umbau) steht in keinem Verhältnis.
Der auskommentierte Cron bleibt entsprechend aus; die Platte (73 % voll) wird nicht weiter
belastet, der Altstand /opt/backup/gitea-dump-2026-07-30.tar.gz kann weg.
Dokumentierte Nuance: was auf rohana kein Spiegel ist
Nicht aus git.lab wiederherstellbar sind die Gitea-Packages (Container-Registry) — der Cluster zieht vier Images ausschließlich von dort:
| Image | Rolle |
|---|---|
threadnet-web:v0.4.3 |
Element-Web-Fork, den die Nutzer im Browser laden |
axion-backup:v2 |
führt die drei nächtlichen Borg-Backups aus (7 Pods) |
axion-secret-rotation:v1 |
TURN-Secret-Rotation |
clamav-http-scanner:v1.0.0 |
client-seitiges Scannen |
Bei Verlust von rohana laufende Pods weiter, aber neue Pods können nicht mehr pullen, bis die Images neu gebaut sind — und Flux verliert zugleich seine Source. Das ist kein Datenverlust (alle vier sind aus dem Quellcode reproduzierbar: Dockerfiles in gitops bzw. den Fork-Repos), sondern Wiederherstellungszeit. Bewusst akzeptiert; die Reproduzierbarkeit des Build-Wegs ist ohnehin über #0022/#0033 adressiert.