Backup und Wiederherstellung

QuoteNode enthält ein integriertes Backup-System, das kaufmännische Daten gegen Hardwareausfälle, versehentliche Löschungen und operative Fehler schützt.

Was ein Backup enthält

Jedes Backup enthält drei Komponenten:

1. Datenbank-Dump — ein vollständiger PostgreSQL-Dump im Custom-Format
2. Dateispeicher — Uploads und erzeugte PDFs als files.tar.gz
3. Integritätsmanifest — eine checksums.sha256-Datei mit SHA-256-Prüfsummen

Online-Backup

Das Standard-Backup läuft ohne Downtime.

Dabei gilt:

• pg_dump erzeugt einen transaktional konsistenten Snapshot der Datenbank, ohne Tabellen zu sperren
• der Dateispeicher wird parallel archiviert
• beide Komponenten können vor der Ablage verschlüsselt werden

Einschränkungen:

• nicht abgeschlossene Transaktionen zum Zeitpunkt des Dumps landen nicht im Backup
• für die meisten Organisationen ist dieses Verhalten korrekt und ausreichend

Offline-Backup

Für maximale Konsistenz, etwa vor großen Upgrades:

1. stoppen Sie die Anwendungskontainer,
2. führen Sie pg_dump direkt gegen PostgreSQL aus,
3. archivieren Sie die Dateivolumes,
4. starten Sie die Anwendung erneut.

Das erfordert ein kurzes Wartungsfenster, eliminiert aber das Restrisiko gerade laufender Änderungen.

Zeitplanung

Backups werden vom Container backup-worker gesteuert, einer dedizierten Backend-Instanz im Modus backup-only:

• Standardzeitplan täglich um 2:00 Uhr
• Aktivierung über BACKUP_ENABLED
• manueller Trigger aus dem Admin-Panel oder per API
• Konkurrenzschutz über SKIP LOCKED, damit nie mehrere Backups parallel laufen

Speicherziele

Lokaler Speicher

Backups werden standardmäßig in BACKUP_LOCAL_DIR gespeichert. Das genügt für Entwicklung und kleine Deployments.

In Produktion sollten lokale Backups durch eine externe Kopie ergänzt werden. Ein Backup auf derselben Disk wie die Datenbank schützt nicht vor Disk-Ausfall.

Remote-Storage via rclone

Wenn BACKUP_RCLONE_REMOTE gesetzt ist, werden Backups nach der Erstellung automatisch in einen Remote-Speicher hochgeladen.

Unterstützt werden unter anderem:

• S3-kompatible Systeme,
• Google Cloud Storage,
• Azure Blob Storage,
• SFTP,
• WebDAV.

Schlägt der Remote-Upload fehl, bleibt das lokale Backup erhalten.

Verschlüsselung

Backups können über GPG verschlüsselt werden:

• setzen Sie BACKUP_GPG_RECIPIENT,
• Datenbank-Dump und Dateiarchiv werden vor der Speicherung verschlüsselt,
• zur Entschlüsselung ist der passende private Schlüssel erforderlich.

Das ist besonders wichtig bei Backups in fremd verwalteter Cloud-Infrastruktur.

Metadaten und Audit

Jedes Backup, erfolgreich oder fehlgeschlagen, wird in backup_logs protokolliert.

Gespeichert werden unter anderem:

• Status,
• Auslöser,
• Start- und Endzeit,
• Größe,
• Zielpfad,
• Checksumme,
• Fehlermeldung.

Wiederherstellung

Vollständiges Restore

1. stoppen Sie alle Container: docker compose down
2. stellen Sie die Datenbank wieder her:

   pg_restore --clean --if-exists -d quotenode backup.dump

3. entpacken Sie den Dateispeicher:

   tar xzf files.tar.gz -C /app/data/

4. starten Sie die Container neu: docker compose up -d
5. prüfen Sie die Checksums gegen das Manifest.

Teilweises Restore

Custom-Format-Dumps erlauben die Wiederherstellung einzelner Tabellen oder Datensätze, was beim gezielten Recover versehentlich gelöschter Informationen hilfreich ist.

Verschlüsselte Backups

Entschlüsseln Sie zuerst:

gpg --decrypt backup.dump.gpg > backup.dump
gpg --decrypt files.tar.gz.gpg > files.tar.gz

Danach folgt die normale Restore-Prozedur.

Backup-Timeout

Jeder Backup-Lauf hat ein Zeitlimit von 30 Minuten. Wird dieses überschritten, bricht das System den Lauf ab und markiert ihn als FAILED.

Backups herunterladen

Administratoren können Backup-Archive direkt im Admin-Panel herunterladen:

1. öffnen Sie Settings > Backup
2. wählen Sie ein erfolgreiches Backup aus
3. klicken Sie auf Download

Das .tar.gz-Archiv enthält Datenbank-Dump, Dateispeicher und Integritätsmanifest. Behandeln Sie diese Datei wie einen kompletten Auszug Ihrer Geschäftsdaten.

Aufbewahrung

Alte lokale Backups werden nach jedem erfolgreichen Lauf automatisch bereinigt. Gesteuert wird das über BACKUP_RETENTION_DAILY.

Remote-Backups werden von QuoteNode nicht gelöscht — dort sollte die Retention-Policy beim Storage-Anbieter definiert werden.

Disaster Recovery von Grund auf

Wenn der ursprüngliche Server verloren ist und nur noch das Backup-Archiv und ein neuer Docker-Server existieren:

Schritt 1 — neuen Server vorbereiten

Legen Sie Projektverzeichnis, docker-compose.yml und .env wie im Installationsleitfaden beschrieben an.

Kritisch: Verwenden Sie denselben DB_ENCRYPTION_KEY wie in der ursprünglichen Installation. Ohne ihn bleiben verschlüsselte Daten unlesbar.

Schritt 2 — Backup kopieren

Übertragen Sie das Archiv per scp, rsync oder ein anderes Transferwerkzeug auf den neuen Server.

Schritt 3 — Restore-Skript bereitstellen

cp /path/to/your/quotenode-repository/scripts/restore.sh .
chmod +x restore.sh

Wenn sich das Repository auf einer anderen Workstation befindet, kopieren Sie dieselbe Datei zuerst auf den Server.

Schritt 4 — Restore ausführen

./restore.sh --fresh-install ~/quotenode/quotenode-backup-20260320.tar.gz

Das Skript:

1. startet die Datenbank,
2. wartet auf Bereitschaft,
3. spielt den Dump ein,
4. startet den gesamten Stack,
5. stellt Dateien und PDFs wieder her,
6. führt einen Health Check aus.

Schritt 5 — prüfen

Öffnen Sie die Domain, melden Sie sich an und kontrollieren Sie, ob Kunden, Angebote, Produkte und Einstellungen dem Zustand des Backups entsprechen.

Dry Run

RESTORE_DRY_RUN=true ./restore.sh --fresh-install backup-file.tar.gz

Damit werden Archiv, Checksums und Restore-Plan geprüft, ohne Datenbank oder Dateispeicher zu verändern.

Empfohlene Strategie

Für Produktion:

1. tägliche automatische Backups aktivieren,
2. Remote-Storage ergänzen,
3. Backups außerhalb der eigenen Infrastruktur verschlüsseln,
4. Restore regelmäßig testen,
5. Backup-Logs überwachen,
6. mindestens 7 Tage Backup-Historie behalten.