Skip to content

Database Backups

Database backups are managed per database service from its Backups tab. A backup belongs to one exact workspace, project, environment, service, and database generation.

Forge reports storage verification and restore testing separately. Encryption, checksum verification, and a verified off-site object prove that the backup bytes are protected and retrievable. Only a successful isolated restore test proves that the recorded database can be recovered with its required roles and permissions.

Backup and restore availability depends on all of the following:

  • The database engine.
  • The server and Forge Agent version running that service.
  • The capabilities reported by that exact Agent.
  • The configured backup destination.
  • The service’s current health and credential state.

The status shown for the exact database service is authoritative. Do not assume that a backup available on one server is available on another. Forge blocks the action when the target has not reported the required qualified capability.

ClickHouse backup and restore are not currently available. Other engines appear as available only when their required capability is present on the selected target.

Depending on the service configuration, Forge can retain a backup on the database server, in the workspace’s configured off-site storage, or in both locations.

  • Server disk is fast, but it does not protect against losing the server.
  • Off-site storage protects against server loss, subject to the configured provider, credentials, and retention policy.
  • Both keeps a recent local copy and an off-site copy.

Forge records the result for each requested destination. A local copy does not make a failed off-site upload successful, and an uploaded object does not count as restore-tested until an isolated recovery drill passes.

  1. Open the database service.
  2. Select Backups.
  3. Confirm the environment, service, database generation, and destination.
  4. Select Create backup.
  5. Wait for the backup record to reach a terminal status.

Create a manual backup before schema migrations, data imports, destructive maintenance, credential changes, or service replacement.

Automatic backups are disabled until a schedule is enabled for the database service. The Backups tab shows the schedule, destination, retention, last result, and next expected run.

Treat a stale, failed, or overdue schedule as an operational incident. Fix the reported cause and create a successful manual backup rather than waiting for the next scheduled attempt.

Each backup record identifies the source service and generation and shows the information customers need to evaluate it:

  • Engine and backup format.
  • Trigger and creation time.
  • Destination result.
  • Size, encryption, and integrity status.
  • Restore-test status and time.
  • Failure or blocked reason.

For PostgreSQL-family databases, a production-grade restore also verifies the database owner, required roles, memberships, grants, and application-role login. Forge does not report a successful restore when those checks fail.

  • Keep at least one current off-site backup with a successful isolated restore test for production databases.
  • Do not delete the last restore-tested backup for a production service.
  • Re-run the restore test after material schema, role, permission, or credential changes.
  • Treat downloaded backup files as sensitive production data.
  • A backup from an older format that lacks the required recovery evidence must be replaced before relying on it.

See Restore and Download for recovery actions and safety checks.