Tarev hat ein 3-Ebenen-Backup. Welcher Restore-Weg passt, hängt vom Ausfall-Szenario ab.
Wann brauche ich Restore?
Drei realistische Szenarien:
- Versehentliches DROP / DB-Korruption — Du hast eine Migration verbockt oder eine wichtige Tabelle geleert. Daten sind weg, aber der Server läuft.
- VM-Komplett-Ausfall in nbg1 — Hetzner-Region nbg1 hat einen Ausfall, deine VM antwortet nicht mehr.
- 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.gzDas Skript stoppt den Backend-Container, dropt die DB, spielt den Dump ein, restartet das Backend. Verify-Steps folgen automatisch.
Stufe 2a — Hetzner-Snapshot zurückspielen
- Hetzner-Cloud-Console: https://console.hetzner.cloud
- Server "tarev-prod" auswählen → Tab "Backups"
- Jüngstes Auto-Backup → "Backup wiederherstellen"
- Hetzner restartet die VM mit dem Snapshot-Zustand (~10-15 Min)
- SSH wieder rein,
docker compose up -dfalls 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 RestoreVoraussetzung: 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