Document issues #6/#15 (Storage Box backups) and #41 (private-network follow-up)

Thore Cimbal
2026-07-28 20:43:55 +02:00
parent 2b724aa8db
commit 46b464ceb1
2 changed files with 24 additions and 2 deletions
+22
@@ -222,6 +222,28 @@ Application (Slug `matrix`) als Blueprint erfasst (`matrix-oidc-provider.yaml`),
[[Authentik-OIDC]] für Details. Client-Secret kommt per `!Env` aus der bestehenden
SOPS-verschlüsselten `authentik-credentials` Secret, nicht inline im Blueprint.
**Update 2026-07-28 (Issues #6 + #15)**: Postgres- und Media-Backups zur neu gebuchten
Hetzner Storage Box BX11 (`u641795.your-storagebox.de`, 1TB) umgesetzt — bewusst gemeinsam
betrachtet statt getrennt, da beide dieselbe Lösung teilen. Zwei CronJobs (`synapse-backup`
in `matrix`, `authentik-backup` in `authentik`), Borg-Backups (verschlüsselt,
dedupliziert), je eigenes Repo + Passphrase auf derselben Box. Retention: 7 daily / 4
weekly / 6 monthly. Custom Image `rohana.axion1337.de/sorb/axion-backup` (`postgres:17-alpine`
+ borgbackup + openssh-client, passt exakt zur laufenden Postgres-Major-Version). SSH-Host-Key
gepinnt statt Trust-on-first-use.
Unterwegs zwei Bugs gefunden und gefixt: (1) `pg_dump` bekam beim Job-Start sofort
"Connection refused" — der NetworkPolicy-Controller braucht ein paar Sekunden, um die IP
eines brandneuen Pods in die erlaubten Ingress-Regeln einzutragen; `backup.sh` wartet jetzt
per `pg_isready`-Retry. (2) Eine Firewall-Fehlkonfiguration schnitt den K3s-Node zeitweise
komplett von `rohana.axion1337.de` ab — als Sofortmaßnahme ein `/etc/hosts`-Eintrag auf dem
Node (`10.0.0.3 rohana.axion1337.de`, beide Server teilen sich ein privates Hetzner-Netzwerk),
sauberer clusterweiter Fix als Issue #41 nachgehalten.
**Echter Restore-Test bestätigt**: beide Repos extrahiert, DB-Dumps valide (Synapse 807 /
MAS 256 / Authentik 1641 TOC-Einträge), alle media_store-Dateien mit Original-Timestamps
intakt. Hetzners eigener monatlicher Storage-Box-Snapshot bleibt zusätzlich aktiv (schützt
die Borg-Repos selbst, komplementär zur Retention).
### Authentik Stage 2 MAS Integration (⏳ Depends on Manual Config) — historisch, siehe Update oben
**Beschreibung**: Authentik OIDC Provider muss manuell im Authentik Admin UI konfiguriert werden, bevor Stage 2 Deployment möglich ist.
+2 -2
@@ -68,9 +68,9 @@ PostgreSQL + TURN (turn.axion1337.chat)
| Category | Count | Status |
|----------|-------|--------|
| **Completed** | 10 | ✅ K3S, Flux, ESS, Themes, Desktop, Monitoring, TURN, Authentik (Enrollment/Recovery/2FA), coturn-Fix, Element Call Fork, NetworkPolicies |
| **Completed** | 14 | ✅ K3S, Flux, ESS, Themes, Desktop, Monitoring, TURN, Authentik (Enrollment/Recovery/2FA), coturn-Fix, Element Call Fork, NetworkPolicies, Authentik OIDC Provider as Code, authentik-postgresql NetworkPolicy, Postgres+Media Backups |
| **In Progress** | 0 | — |
| **Backlog** | 12+ | 📋 DB Backups, PostgreSQL Migration, MAS custom-template account link, VP9-Retry, etc. |
| **Backlog** | 30+ | 📋 tracked as individual Gitea issues (#9, #11-#41), see [[00-TASKS]] |
| **Security** | 10 | 🔒 Firewall, SSH, auditd, Kernel hardening, CrowdSec, Falco |
---