Backups und Wiederherstellungstest

Jeder Server mit Postgres hat einen Backup-Container (infrastructure/docker/backup).

#Nächtliches Backup

• 03:00 Uhr (BACKUP_SCHEDULE): pg_dump -Fc aller Datenbanken
• verschlüsselt (rclone crypt, BACKUP_ENCRYPTION_PASSWORD) in den Objektspeicher unter postgres/<datenbank>/
• Aufbewahrung BACKUP_RETENTION_DAYS (30)
• Ergebnis je Datenbank an die Plattform

#Mehrere Server (Backup-Quellen)

Der Hauptserver (main) schreibt direkt in die Plattform-Datenbank. Shop-Server melden per HTTPS als eigene Quelle:

pnpm platform backup source shops-1 --name "Shop-Server 1" \
  --file infrastructure/docker/docker-compose.shops-infra.dokploy.yml

Das legt die Quelle mit neuem Token an (gespeichert als Hash), setzt BACKUP_SOURCE, BACKUP_REPORT_URL und BACKUP_REPORT_TOKEN im Infra-Stack des Servers und deployt neu.

#Warnungen

Die Plattform öffnet eine Störung und mailt der Agentur, wenn ein Dump fehlschlägt oder seit PLATFORM_BACKUP_MAX_AGE_HOURS (26) kein Lauf kam – je Server – und meldet die Erholung.

#Wiederherstellungstest

Ein Backup zählt erst, wenn es sich einspielen lässt. Am 1. jedes Monats um 04:00 (BACKUP_VERIFY_SCHEDULE) spielt jeder Container den letzten Dump jeder Datenbank in eine temporäre Datenbank <db>__verify, vergleicht Tabellen und Zeilen mit dem Original und löscht die Kopie. Ergebnis unter Agentur → Backups; ein Fehler oder kein Test seit 35 Tagen öffnet eine Störung.

pnpm platform backup run shops-1            # Backup jetzt
pnpm platform backup run shops-1 --verify   # Wiederherstellungstest jetzt

#Wiederherstellen

Im Backup-Container (Dokploy-Terminal):

backup-list shop2_medusa
backup-restore shop2_medusa latest shop2_medusa_check   # daneben einspielen, prüfen
backup-restore shop2_medusa latest                       # ersetzen (Shop vorher stoppen)

Ein ganzer Shop sind drei Datenbanken: <id>_medusa, <id>_payload, <id>_auth. Medien liegen im Objektspeicher und sind nicht Teil der Dumps.