Backing up and restoring your databases

MobilityManager keeps all persistent data in its databases: a system database and one or more tenant databases. Protecting that data means backing up both, plus the secrets needed to read it. This article gives practical backup and restore guidance.

What to back up

• System database (SystemConnection) — the tenant registry, users, roles, and license.
• Tenant database(s) (TenantConnection and per-tenant databases) — fleet, booking, and operational data.
• Secrets — the Jwt__Key and the DocumentStorage__LocalEncryptionKey.
• Stored documents — any local document storage directory, if you use local storage.

Warning: A database backup is not enough on its own. If you lose the document encryption key, encrypted documents in a restored database cannot be decrypted. Back up keys separately and securely.

Backing up PostgreSQL

Use pg_dump for each database. For the Docker Compose stack, run it inside the database container:

docker exec mobilitymanager-postgres \
  pg_dump -U mobilitymanager mobilitymanager_system > system-backup.sql

docker exec mobilitymanager-postgres \
  pg_dump -U mobilitymanager mobilitymanager_tenant > tenant-backup.sql

Backing up SQL Server

For SQL Server, use native BACKUP DATABASE statements or your platform's managed backups. On Azure SQL, rely on automated backups and point-in-time restore, and export a .bacpac for portable copies.

Tip: Keep the backup provider consistent with your DatabaseProvider. You cannot restore a PostgreSQL dump into SQL Server or vice versa without a data migration.

Restoring

1. Provision empty target databases matching your provider.
2. Restore the system database first, then the tenant database(s).

   psql -U mobilitymanager -d mobilitymanager_system < system-backup.sql
   psql -U mobilitymanager -d mobilitymanager_tenant < tenant-backup.sql

3. Restore the Jwt__Key and document encryption key to their secret store.
4. Point SystemConnection and TenantConnection at the restored databases and start the application.
5. On startup the app applies any pending migrations, so a backup from an older schema is brought up to date automatically.

Verify the restore

• Check /healthz returns 200.
• Sign in and confirm tenants, users, and recent records are present.
• Open an encrypted document to confirm the encryption key was restored correctly.

Note: Test restores on a regular schedule against a non-production target. An untested backup is not a reliable backup.

Related

• Configuring the database connection strings
• Configuring the document encryption-at-rest key
• Migrations and the onboarding redirect on startup
• Production hardening checklist