Skip to content

Enterprise backup and restore

Architecture

Enterprise uses PostgreSQL exclusively. The Enterprise Client configures and requests operations; FleetMiraWorker performs all database, archive, upload, verification, retention and restore work. The client never starts a local backup worker and never uses the SQLite snapshot service.

A set contains a PostgreSQL 17 custom dump, versioned manifest, commit marker, and SHA-256-deduplicated DDD, financial and record archives. It becomes VERIFIED only after every component has been uploaded, read back, decrypted and checked.

Prerequisites and roles

The server setup creates mira_owner (NOLOGIN), mira_app, mira_backup, and mira_restore. The worker component installs PostgreSQL 17 pg_dump, pg_restore, and psql. Passwords do not appear in arguments, logs, or PostgreSQL configuration tables.

The first worker creates an RSA-3072 deployment key. Private material is machine-protected and ACL-restricted to System, administrators, and FleetMiraWorker; PostgreSQL stores only the public key. Use tools\manage-enterprise-backup-key.ps1 to export or import it for additional workers.

Configure a target

Create exactly one active target under Administration → Backups: file system/UNC, HTTPS WebDAV, or Google Drive (drive.file, My Drive or Shared Drive). Google Drive is one-way backup, not synchronisation. Export and store the recovery key offline, then run the upload/read-back test.

Defaults are 02:00 server time and 14 daily, 8 weekly, and 12 monthly versions. Archives are never removed by database retention. beta6 does not include PITR/WAL archiving.

Controlled restore

  1. Select a verified set, enter the mandatory reason and choose Prepare restore.
  2. The worker verifies the dump and archives and restores a staging database.
  3. Schema, tables and archive references are checked; status becomes READY_FOR_APPROVAL.
  4. A user with backup.restore selects Approve production switch.
  5. Maintenance mode is enabled, production is retained as a rollback database, and staging becomes production.
  6. Archive replacement is prepared atomically; failure triggers rollback.
  7. The previous database is retained for seven days.

After cutover, verify sign-in, worker heartbeat, imports, DDD output, financial and record archives, and create a fresh backup. Customer-like Windows Server VM acceptance remains mandatory for UNC/gMSA, OAuth, large datasets and network interruption.