Backup & Restore Runbook
Executive Overview — all summaries for decision-makers.
Übersicht
| Komponente | Backup-Methode | Frequenz (Soll) | Speicherort |
|---|---|---|---|
| PostgreSQL | Render PITR (Pro Plan) | Kontinuierlich | Render Frankfurt |
| PostgreSQL | pg_dump Directory-Format | Monatlich | Cloudflare R2 (MQA) |
| R2 Media | R2 Versioning / Replikation | Bei Migration aktivieren | Cloudflare |
Render Uploads (/uploads) | ⚠️ Ephemeral | — | Migration zu R2 geplant |
Automatisches Backup (Script)
bash
# Voraussetzung: DATABASE_URL (External URL mit sslmode=require)
export DATABASE_URL='postgresql://...'
./backend/scripts/backup-production-db.sh
# Output: ./backups/mqa_governance_YYYY-MM-DD_HHMM.dir.tar.gzUpload des Archives nach R2 (manuell oder Cron):
bash
# Beispiel mit rclone (nach Konfiguration MQA-R2-Remote)
rclone copy backups/ mqa-r2:backups/postgres/Restore (Production)
Vorsicht: Überschreibt bestehende DB-Objekte.
- Maintenance-Fenster ankündigen
- Render Backend skalieren pausieren oder Maintenance-Mode
- Restore ausführen → DATABASE-RESTORE
- Migrationen synchronisieren:
bash
cd backend
npx prisma migrate deploy
# Bei Konflikten (Schema bereits im Dump):
npx prisma migrate resolve --applied <migration_name>- Smoke-Tests → DEPLOYMENT-CHECKLIST
- Backend redeployen
Render Postgres PITR
Im Render Dashboard → mqa-postgres → Backups → Point-in-Time Recovery.
Nutzen bei versehentlichem DELETE, nicht bei Schema-Migration-Fehlern.
Restore-Test (vierteljährlich)
| Schritt | Erwartung |
|---|---|
| Backup von R2 laden | Archiv intakt |
| In Staging-DB restoren | Kein Fehler |
User-Count prüfen | > 0 |
| Login OAuth auf Staging | Funktioniert |
| Dokumentieren | Datum + Verantwortlicher in OPS-ROADMAP |
Notfall-Kontakte
| Rolle | Aktion |
|---|---|
| Lead Developer | Restore ausführen, Deploy |
| MQA IT | DNS, Azure, Cloudflare |
| Render Support | DB PITR, Platform-Ausfall |
Änderungshistorie
| Datum | Ereignis |
|---|---|
| 2026-08-03 | Prod-DB aus Juni-2026-Dump restored; Runbook erstellt |