Backup wiederherstellen (Disaster-Recovery)

Tarev hat ein 3-Ebenen-Backup. Welcher Restore-Weg passt, haengt vom Ausfall-Szenario ab.

Wann brauche ich Restore?

Drei realistische Szenarien:

1. Versehentliches DROP / DB-Korruption — Du hast eine

Migration verbockt oder eine wichtige Tabelle geleert. Daten sind weg, aber der Server läuft.

1. VM-Komplett-Ausfall in nbg1 — Hetzner-Region nbg1 hat einen

Ausfall, deine VM antwortet nicht mehr.

1. Hetzner-Total-Ausfall — Konkurs, Sanktion, Region weg. Du

musst auf einem fremden Cloud-Provider neu hochfahren.

Stufe-Wahl je Szenario

| Szenario | Quelle | Recovery-Zeit | |---|---|---| | DB-Korruption | Stufe 1 — lokaler pg_dump in /var/lib/tarev-backups/db/ | ~5 Min | | VM-Ausfall nbg1 | Stufe 2a — Hetzner VM-Auto-Backup (fsn1) | ~30 Min | | nbg1 down, fsn1 ok | Stufe 2b — rclone aus Object-Storage | ~45 Min | | Hetzner total weg | Stufe 2b-alt — StorageBox/S3 auf fremder Cloud | ~90 Min |

Stufe 1 — lokaler Restore (häufigster Fall)

ssh root@tarev.de
cd /opt/tarev/scripts
ls -lt /var/lib/tarev-backups/db/ | head -5
# jüngsten Dump finden, z.B. tarev-2026-05-21_03-30-00.sql.gz
sudo bash restore-db.sh /var/lib/tarev-backups/db/tarev-2026-05-21_03-30-00.sql.gz

Das Skript stoppt den Backend-Container, dropt die DB, spielt den Dump ein, restartet das Backend. Verify-Steps folgen automatisch.

[Screenshot: SSH-Session mit erfolgreich beendetem restore-db.sh]

Stufe 2a — Hetzner-Snapshot zurückspielen

1. Hetzner-Cloud-Console: https://console.hetzner.cloud
2. Server "tarev-prod" auswählen → Tab "Backups"
3. Juengstes Auto-Backup → "Backup wiederherstellen"
4. Hetzner restartet die VM mit dem Snapshot-Zustand (~10-15 Min)
5. SSH wieder rein, docker compose up -d falls nötig

Stufe 2b — Off-Site-Restore via rclone

Volltext-Doku: deploy/backup/RESTORE_FROM_OFFSITE.md. Kurzfassung:

# Auf einer neuen Recovery-VM (z.B. Hetzner fsn1 oder anderer Cloud)
git clone https://github.com/Tarev-io/Takt /opt/tarev
cd /opt/tarev
sudo bash deploy/backup/setup-offsite.sh
sudo bash deploy/backup/restore-drill.sh     # Trockenlauf
sudo bash deploy/backup/restore-db.sh        # echter Restore

Voraussetzung: rclone.conf mit S3-Credentials liegt im Owner- Passwort-Safe. Wenn die nicht erreichbar ist — separat dokumentiert in README-stufe2b.md.

Verify-Steps nach jedem Restore

# 1. DB-Connectivity
docker exec tarev-postgres psql -U tarev -c "SELECT count(*) FROM \"User\";"

# 2. Backend-Health
curl https://tarev.de/api/health/full

# 3. Tenant-Audit
docker exec tarev-backend node scripts/tenant-audit.js

# 4. Login-Test mit Test-User
curl -X POST https://tarev.de/api/auth/login -d '{...}'

Wenn alle 4 grün: Restore erfolgreich. Admin-User per Mail informieren.

Wo gibt's Hilfe bei Problemen

• Repo: deploy/backup/README.md (Stufe 1 + 2a)
• Repo: deploy/backup/RESTORE_FROM_OFFSITE.md (Stufe 2b rclone)
• Repo: deploy/backup/README-stufe2b.md (Stufe 2b StorageBox)
• Support: support@tarev.de (Antwortzeit innerhalb 1h bei

Disaster-Mail mit "RESTORE" im Betreff)

Verwandte Artikel

• VAPID-Keys einrichten für Push-Notifications
• Stripe-Setup für Pusteblume-Abos