Enterprise-Backup und Wiederherstellung

Architektur

Enterprise verwendet ausschließlich PostgreSQL. Der Enterprise Client konfiguriert und beauftragt Sicherungen; FleetMiraWorker führt Datenbank-, Archiv-, Upload-, Verifikations-, Retentions- und Restore-Arbeiten aus. Der Client startet keinen lokalen Backupworker und verwendet nie den SQLite-Snapshotdienst.

Ein Sicherungssatz enthält einen PostgreSQL-17-Custom-Dump, versioniertes Manifest, Commit-Marker und die anhand SHA-256 deduplizierten DDD-, Finanz- und Aktenarchive. VERIFIED wird erst nach vollständigem Upload, Rücklesen, Entschlüsselung und Prüfung aller Bestandteile gesetzt.

Voraussetzungen und Rollen

Das Server-Setup erzeugt mira_owner (ohne Anmeldung), mira_app, mira_backup und mira_restore. Das Worker-Setup installiert pg_dump, pg_restore und psql 17. Kennwörter erscheinen nicht in Argumenten, Logs oder PostgreSQL-Konfigurationstabellen.

Der erste Worker erzeugt einen RSA-3072-Deployment-Schlüssel. Privates Material wird maschinengebunden geschützt und per ACL auf System, Administratoren und FleetMiraWorker beschränkt; PostgreSQL enthält nur den öffentlichen Schlüssel. Für weitere Worker dient tools\manage-enterprise-backup-key.ps1 zum geschützten Export und Import.

Ziel konfigurieren

Unter Administration → Backups wird genau ein aktives Ziel angelegt: Dateisystem oder UNC, HTTPS-WebDAV oder Google Drive (drive.file, My Drive oder Shared Drive). Google Drive ist eine einseitige Sicherung, keine Synchronisierung. Den Recovery-Key beim Speichern exportieren, offline verwahren und anschließend den Upload- und Rücklesetest ausführen.

Standard sind täglich 02:00 Uhr Serverzeit sowie 14 tägliche, 8 wöchentliche und 12 monatliche Stände. Archive werden nicht durch die Datenbankretention gelöscht. PITR/WAL-Archivierung ist in beta6 nicht enthalten.

Kontrollierte Wiederherstellung

1. Verifizierten Stand wählen, Pflichtgrund erfassen und Prepare restore ausführen.
2. Der Worker prüft Dump und Archive und restauriert in eine Staging-Datenbank.
3. Nach Schema-, Tabellen- und Archivreferenzprüfung folgt READY_FOR_APPROVAL.
4. Ein Benutzer mit backup.restore bestätigt Approve production switch.
5. Wartungsmodus wird aktiviert; Produktion wird als Rollback-Datenbank erhalten und das Staging kontrolliert aktiviert.
6. Archive werden atomar vorbereitet und ersetzt; Fehler lösen die Rückschaltung aus.
7. Der vorherige Datenbankstand bleibt sieben Tage erhalten.

Danach Anmeldung, Worker-Heartbeat, Import, DDD-Ausgabe, Finanz- und Aktenarchive sowie eine neue Sicherung prüfen. Für UNC/gMSA, OAuth, große Datenmengen und absichtliche Netzwerkabbrüche bleibt die Abnahme auf einer kundennahen Windows-Server-VM Pflicht.