Vor dem Live-Verkauf belegen, dass sich die Datenbank aus dem nächtlichen Dump wiederherstellen lässt, und klären, wer die zweite Datenbank derselben Instanz sichert.
Offen
Einen Dump aus artista-db-backup in einen Test-Namespace einspielen (pg_restore, Ablauf docs/BETRIEB.md Abschnitt 7), App dagegen starten, Ergebnis und Dauer hier dokumentieren
Klären, ob die Datenbank telefonie (Artista-Telefonie, gleiche Instanz artista-modelcamp-postgres) gesichert wird; der CronJob dumpt nur artista. Entweder zweiter Dump im selben CronJob oder eigener CronJob im Repo Artista-TeleTracking
Medien: festhalten, wie modelcamp-media auf der Storage Box gesichert ist
Offene Entscheidungen
Wo die Sicherung der Telefonie-Datenbank hingehört (dieses Repo oder Artista-TeleTracking).
## Ziel
Vor dem Live-Verkauf belegen, dass sich die Datenbank aus dem nächtlichen Dump wiederherstellen lässt, und klären, wer die zweite Datenbank derselben Instanz sichert.
## Offen
- [ ] Einen Dump aus `artista-db-backup` in einen Test-Namespace einspielen (`pg_restore`, Ablauf `docs/BETRIEB.md` Abschnitt 7), App dagegen starten, Ergebnis und Dauer hier dokumentieren
- [ ] Klären, ob die Datenbank `telefonie` (Artista-Telefonie, gleiche Instanz `artista-modelcamp-postgres`) gesichert wird; der CronJob dumpt nur `artista`. Entweder zweiter Dump im selben CronJob oder eigener CronJob im Repo `Artista-TeleTracking`
- [ ] Medien: festhalten, wie `modelcamp-media` auf der Storage Box gesichert ist
## Offene Entscheidungen
Wo die Sicherung der Telefonie-Datenbank hingehört (dieses Repo oder `Artista-TeleTracking`).
## Grundlage
`docs/BETRIEB.md` Abschnitt 7, `k8s/09-db-backup-cronjob.yaml`, #18.
## Status
Code: nein · Geprüft: nein · Gemergt: nein · Produktiv: nein
Stand: 2026-10-16 (Quelle: git origin/main 9785eb2, Gitea-CI-Läufe und Registry, Memory der Sessions)
Stand 2026-10-16 (Abgleich im Repo RKE2-Cluster): Die Telefonie-Datenbank wird seit 2026-10-15 vom CronJob artista-telefonie-db-backup gesichert, gepflegt im Repo Artista-TeleTracking. Der Punkt „Sicherung der Telefonie-Datenbank klären“ ist damit erledigt. Offen bleibt die geübte Wiederherstellung. Cluster-weite Sicherungsstrategie: Nick.Rosenloecher/RKE2-Cluster#28.
Stand 2026-10-16 (Abgleich im Repo RKE2-Cluster): Die Telefonie-Datenbank wird seit 2026-10-15 vom CronJob `artista-telefonie-db-backup` gesichert, gepflegt im Repo Artista-TeleTracking. Der Punkt „Sicherung der Telefonie-Datenbank klären“ ist damit erledigt. Offen bleibt die geübte Wiederherstellung. Cluster-weite Sicherungsstrategie: Nick.Rosenloecher/RKE2-Cluster#28.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ziel
Vor dem Live-Verkauf belegen, dass sich die Datenbank aus dem nächtlichen Dump wiederherstellen lässt, und klären, wer die zweite Datenbank derselben Instanz sichert.
Offen
artista-db-backupin einen Test-Namespace einspielen (pg_restore, Ablaufdocs/BETRIEB.mdAbschnitt 7), App dagegen starten, Ergebnis und Dauer hier dokumentierentelefonie(Artista-Telefonie, gleiche Instanzartista-modelcamp-postgres) gesichert wird; der CronJob dumpt nurartista. Entweder zweiter Dump im selben CronJob oder eigener CronJob im RepoArtista-TeleTrackingmodelcamp-mediaauf der Storage Box gesichert istOffene Entscheidungen
Wo die Sicherung der Telefonie-Datenbank hingehört (dieses Repo oder
Artista-TeleTracking).Grundlage
docs/BETRIEB.mdAbschnitt 7,k8s/09-db-backup-cronjob.yaml, #18.Status
Code: nein · Geprüft: nein · Gemergt: nein · Produktiv: nein
Stand: 2026-10-16 (Quelle: git origin/main
9785eb2, Gitea-CI-Läufe und Registry, Memory der Sessions)Stand 2026-10-16 (Abgleich im Repo RKE2-Cluster): Die Telefonie-Datenbank wird seit 2026-10-15 vom CronJob
artista-telefonie-db-backupgesichert, gepflegt im Repo Artista-TeleTracking. Der Punkt „Sicherung der Telefonie-Datenbank klären“ ist damit erledigt. Offen bleibt die geübte Wiederherstellung. Cluster-weite Sicherungsstrategie: Nick.Rosenloecher/RKE2-Cluster#28.