kai/pingu-concerts
1
0
Fork 0
Code Issues 10 Pull Requests Actions Packages Projects Releases Wiki Activity

[P1] PostgreSQL- und Upload-Backups mit Restore-Test einrichten #12

New Issue
Open
opened 2026-09-15 09:43:33 +00:00 by metalcircle-bot · 0 comments
metalcircle-bot commented 2026-09-15 09:43:33 +00:00
Copy Link
Copy Source

Ziel

Konten, Konzerte und hochgeladene Dateien nach einem Betriebsfehler wiederherstellen können, bevor echte Beta-Daten entstehen.

Hintergrund

Die Compose-Datei nutzt persistente Volumes für PostgreSQL, öffentliche Uploads und private Uploads. Persistente Volumes allein schützen nicht vor Datenträgerausfall, Fehlbedienung oder beschädigter Datenbank.

Ist-Zustand

Die Repository-Dokumentation hält ausdrücklich fest, dass keine verlässliche Backup-, Aufbewahrungs- oder Restore-Strategie beschrieben ist. Es gibt im Repository keinen belegten Backup-/Restore-Ablauf oder erfolgreichen Restore-Test.

Anforderungen

  • Sicherung von PostgreSQL und sämtlichen Upload-Verzeichnissen konsistent planen; Zeitplan, Aufbewahrung, Verschlüsselung, Zugriff und Verantwortlichkeit festlegen.
  • Sicherungen außerhalb des betroffenen Container-/Datenvolumes ablegen.
  • Wiederherstellung in eine isolierte Testumgebung dokumentieren und regelmäßig prüfen.
  • Backup-Zugangsdaten und Schlüssel nicht ins Repository oder in Logs schreiben.
  • Datenschutz- und Löschfristen mit dem rechtlich freigegebenen Datenkonzept abstimmen.

Akzeptanzkriterien

  • Backup umfasst Datenbank und öffentliche/private Uploads.
  • Sicherung ist gegen unbefugten Zugriff geschützt und nicht nur im selben Volume abgelegt.
  • Dokumentierter Restore stellt eine isolierte Instanz einschließlich Verknüpfungen/Bildern wieder her.
  • Restore-Test ist mit Datum, Ergebnis und gemessener Dauer dokumentiert.
  • Betreiber kennt Wiederherstellungsweg und Aufbewahrungsgrenzen.

Test / Verifikation

Beta-nahe Kopie sichern, in eine isolierte Umgebung wiederherstellen und Login, Konzertdetails, Bilder, private Tagebuchbilder und Datenbankbeziehungen stichprobenartig prüfen.

Abhängigkeiten

Freigegebene Beta-Umgebung und Speicherort; keine laufende Umgebung im Rahmen dieses Issues ungefragt verändern.

## Ziel Konten, Konzerte und hochgeladene Dateien nach einem Betriebsfehler wiederherstellen können, bevor echte Beta-Daten entstehen. ## Hintergrund Die Compose-Datei nutzt persistente Volumes für PostgreSQL, öffentliche Uploads und private Uploads. Persistente Volumes allein schützen nicht vor Datenträgerausfall, Fehlbedienung oder beschädigter Datenbank. ## Ist-Zustand Die Repository-Dokumentation hält ausdrücklich fest, dass keine verlässliche Backup-, Aufbewahrungs- oder Restore-Strategie beschrieben ist. Es gibt im Repository keinen belegten Backup-/Restore-Ablauf oder erfolgreichen Restore-Test. ## Anforderungen - Sicherung von PostgreSQL und sämtlichen Upload-Verzeichnissen konsistent planen; Zeitplan, Aufbewahrung, Verschlüsselung, Zugriff und Verantwortlichkeit festlegen. - Sicherungen außerhalb des betroffenen Container-/Datenvolumes ablegen. - Wiederherstellung in eine isolierte Testumgebung dokumentieren und regelmäßig prüfen. - Backup-Zugangsdaten und Schlüssel nicht ins Repository oder in Logs schreiben. - Datenschutz- und Löschfristen mit dem rechtlich freigegebenen Datenkonzept abstimmen. ## Akzeptanzkriterien - [ ] Backup umfasst Datenbank und öffentliche/private Uploads. - [ ] Sicherung ist gegen unbefugten Zugriff geschützt und nicht nur im selben Volume abgelegt. - [ ] Dokumentierter Restore stellt eine isolierte Instanz einschließlich Verknüpfungen/Bildern wieder her. - [ ] Restore-Test ist mit Datum, Ergebnis und gemessener Dauer dokumentiert. - [ ] Betreiber kennt Wiederherstellungsweg und Aufbewahrungsgrenzen. ## Test / Verifikation Beta-nahe Kopie sichern, in eine isolierte Umgebung wiederherstellen und Login, Konzertdetails, Bilder, private Tagebuchbilder und Datenbankbeziehungen stichprobenartig prüfen. ## Abhängigkeiten Freigegebene Beta-Umgebung und Speicherort; keine laufende Umgebung im Rahmen dieses Issues ungefragt verändern.
kai added this to the MetalCircle 0.1 Beta milestone 2026-09-15 09:52:18 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
android
Betrifft die MetalCircle-Android-App oder die Capacitor-/Android-Integration.
 backend
Betrifft FastAPI, serverseitige Logik, Datenbank oder interne APIs.
 bug
Fehler oder unerwartetes Verhalten, das behoben werden muss.
 database
Betrifft PostgreSQL, Datenmodell, Migrationen oder Datenintegrität.
 deployment
Betrifft Docker, Staging, Production, Deployment oder Infrastruktur.
 enhancement
Verbesserung oder neue Funktion, kein bestehender Fehler.
 frontend
Betrifft Benutzeroberfläche, Templates, JavaScript, Styling oder Interaktionen.
 push
Betrifft Firebase Cloud Messaging, Push-Registrierung oder Benachrichtigungen.
 reported-from-metalcircle
Automatisch über den integrierten MetalCircle-Bugreporter erstellt.
 security
Sicherheitsrelevantes Problem oder notwendige Härtungsmaßnahme.
 web
Betrifft die Web-Version von MetalCircle oder browserspezifisches Verhalten.
No Label
Milestone
No items
No Milestone MetalCircle 0.1 Beta
Projects
Clear projects
No project
Assignees
Clear assignees
codex-bot (MetalCircle Codex Bot) kai
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kai/pingu-concerts#12
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?