Backup and restore

Use Backups to create a backup, manage the daily schedule, inspect retained artifacts, and replace a live database from an eligible completed backup.

Availability by plan and provider

Provider and region availability follows the live create catalog. AWS-backed paths can exist for current or non-production deployments even when AWS is not available for a new production database.

Before you begin

You need:

• an organization owner or administrator role to create, schedule, pause, run, or restore backups
• a Dedicated or Production database with an active profile
• a supported GCP or AWS backup runtime
• no active backup, restore, provisioning, import, or decommission operation that makes the profile unavailable or conflicts with recovery
• enough retained time to finish the restore before the selected artifact expires
• an application downtime and write-freeze plan before restoring

For production recovery, record the current provider, region, node count, vCPU, memory, storage, network mode, development mode, and TigerBeetle version. Restore requires these values to match the backup.

Open Backups

1. Select the organization.
2. Open the dedicated database from Dashboard.
3. Select Backups in the database navigation.

The page is divided into:

• Create new backup
• Backup history
• Backup storage
• Restore from backup
• Backup schedule

Inspect backup history and storage

The default history interval covers the recent week. To change it:

1. Enter From and To dates.
2. Select Apply.

If From is later than To, the route returns to its default recent interval. The page lists up to 50 matching backup jobs.

The history table contains:

Backup storage summarizes the selected date range: stored backup count, total size, latest backup, and the organization's current retention period.

Create a manual backup

1. Confirm the database is Ready and no backup is running.
2. Open Backups.
3. Select Create new backup.
4. Wait for the success message Backup job queued.
5. Keep the page open or return to it; while a backup is active, the page refreshes status every five seconds.
6. Confirm the history row reaches completed and shows the expected replica-artifact count and size.

The action is disabled when the profile is missing or not active, the provider is unsupported, a submission is in progress, or another backup is running.

Backup workflow behavior

Parix validates the organization, plan, profile, provider metadata, runtime configuration, decommission state, and active-job guard. It then creates a backup job and queues the provider workflow.

Only completed is a recoverable outcome. A queued or running row is not yet a usable recovery point.

Expected result

A completed backup has one artifact for every declared replica, retained object data, and restore metadata. The history size and artifact count should be nonzero before you treat it as a verified recovery point.

Manage automatic backups

The Backup schedule card shows:

• Status: active or paused
• Cadence
• Next run
• Last scheduled run
• the last schedule error, when present

Enable daily backups

1. Open Backup schedule.
2. Select Enable daily backups.
3. Confirm the status becomes active and cadence becomes Daily.
4. Confirm Next run is populated.

The schedule model accepts intervals from 1 through 168 hours, but the current customer dashboard exposes a fixed 24-hour enable action rather than an editable cadence field.

Run the schedule now

Select Run scheduled backup now to force the active schedule immediately, even when its normal nextRunAt is still in the future. Success means a backup job was queued; follow it in Backup history. The forced attempt also moves the next scheduled run to one interval after that attempt.

The action is disabled while another backup is running.

Pause or resume

Select Pause schedule to stop future scheduled dispatches. Existing completed artifacts remain subject to retention, and an already running backup is not cancelled by pausing the schedule.

Select Enable daily backups to resume a paused schedule at the dashboard's 24-hour cadence.

Set artifact retention

Completed backup artifacts are retained for 7 days by default. Organization owners and administrators can change the organization-wide period:

1. Open organization Settings.
2. Find Backup retention period.
3. Enter an integer from 1 through 365 days.
4. Save the organization settings.

Retention is evaluated from backup completion time, falling back to creation time when needed. Expired cleanup removes:

• exported backup objects
• provider snapshots when present
• replica-artifact metadata
• the completed backup job metadata

Database deletion removes the automatic schedule but does not immediately purge already completed manual or scheduled artifacts. Existing artifacts remain until the organization retention period expires. Because the deleted database is no longer an available live restore target in the normal UI, do not use post-deletion retention as your only recovery procedure.

Restore a completed backup

Restore is an in-place replacement of the live database, not a read-only verification and not a clone operation.

Eligibility checks

The Restore action is enabled only when all of these are true:

• the target database profile exists and is active
• the provider is GCP, or AWS with Local NVMe
• the backup status is completed
• artifacts exist for every declared replica
• every artifact includes current restore metadata
• required provider snapshot references exist when the backend uses them
• backup region matches the current region
• node count matches
• vCPU and memory per node match
• storage capacity matches
• deployment network mode matches
• TigerBeetle development mode matches
• TigerBeetle version matches the current profile
• no backup, provisioning, restore, or decommission operation conflicts with the restore

The history row displays the first failed eligibility reason. A backup created before restore metadata was captured cannot be repaired in place; create a new backup.

Restore steps

1. Freeze application writes and notify users of downtime.
2. In Backup history, identify the completed recovery point by its timestamp, artifact count, and size.
3. Select Restore.
4. Review the backup identifier and replica-artifact count in the dialog.
5. Type the database name exactly in Database name.
6. Select Queue restore.
7. Wait while the profile reports Provisioning. The page checks active restore state every five seconds.
8. Do not resume writes until the restore job completes, the profile returns to active, and the database is Ready.
9. Run read verification before reopening write traffic.

Destructive and downtime warning

Restore decommissions the current provider resources and reprovisions the database from the selected backup. The database is unavailable during this replacement.

All live changes made after the backup recovery point are discarded from the restored database. The typed-name confirmation is the last guard before queueing this destructive operation. There is no cancel control after the workflow starts and no automatic point-in-time merge with newer live data.

Restore workflow behavior and expected result

Restore jobs use queued, running, completed, and failed states. Queueing moves the profile to Provisioning. On success, Parix persists the restored provider metadata and TigerBeetle version, marks the profile active, and marks the restore job completed.

If restore fails after replacement work begins, the restore job becomes failed and the profile becomes Error. Keep the application write freeze in place and escalate with the database name, backup identifier, provider, and failure time.

Current limitations

• Shared Developer backups and restores are managed by Parix and are not customer self-service surfaces.
• Manual and scheduled backups currently support GCP and implemented AWS runtimes only.
• AWS restore is restricted to Local NVMe; AWS EBS backups are not currently eligible for in-place restore.
• Restore cannot change region, node count, compute, storage, network mode, development mode, or TigerBeetle version.
• Restore cannot use incomplete, failed, running, legacy-metadata, or expired backups.
• The page restores only into the current live database shape. It does not expose clone-from-backup.
• Point-in-time recovery is not available. See Point-in-time recovery.

Troubleshooting

Backups is missing from navigation

The database is on a Developer/shared plan. Self-service backup and restore are intentionally hidden.

Create new backup is disabled

Check the warning under the page header. The profile must exist, be active, and use GCP or AWS. Wait for an active backup or lifecycle workflow to finish. Confirm your role is owner or administrator.

A backup remains queued or running

Keep the page open long enough for a refresh, then check provider health and Logs. Do not queue duplicate backups; the active-job guard rejects them.

A scheduled backup did not run

Confirm that the schedule is active, inspect Next run, Last scheduled run, and the last error. Use Run scheduled backup now once after resolving the error; success should create a new history row.

Restore is disabled

Read the message below the Restore button. The most common causes are an incomplete replica set, a backup made before restore metadata existed, a changed cluster shape or TigerBeetle version, an AWS EBS profile, or another active lifecycle operation.

Restore failed

1. Keep application writes stopped.
2. Record the backup identifier and failed time.
3. Check database status and Logs.
4. Do not queue another restore until the current job is terminal and the profile state is understood.
5. Escalate immediately if the profile is Error, because the live resources may already have been replaced.

For the combined checklist, see Observability, backups, and CDC.

Next steps

• Read Point-in-time recovery so incident plans do not assume unsupported timestamp recovery.
• Review Storage configurations before a backup-driven storage migration.
• Use Metrics and a safe read operation to verify a completed restore.