Point-in-time recovery

Understand the current PITR boundary and use an eligible completed backup as the supported recovery alternative.

Point-in-time recovery (PITR) is not available in the current Parix product.

You cannot choose an arbitrary timestamp, transaction boundary, or moment between completed backups. This limitation applies to Developer, Dedicated, and Production databases and to every provider.

Availability by plan

Database plan	PITR	Supported recovery surface
Developer (shared)	Not available	Shared-cell recovery is managed by Parix; no customer self-service backup restore is exposed.
Dedicated / Production	Not available	Replace the current live database from an eligible completed backup on a supported provider.

Before an incident

Because PITR cannot be used during recovery, prepare these prerequisites in advance:

enable daily backups for each eligible dedicated database
run a manual backup before a high-risk deployment or data migration
choose an organization retention period from 1 through 365 days that covers the required recovery window
verify that completed backups show all replica artifacts and nonzero size
document the downtime and write-freeze procedure for an in-place restore
keep an application-level reconciliation or export strategy when daily recovery points are not granular enough

Backup retention is not PITR. Keeping an artifact for more days only keeps that completed recovery point available for longer.

There is no PITR page, timestamp field, recovery slider, API operation, or queue action in the current dashboard.

For the supported backup-recovery controls:

Select the organization.
Open the dedicated database from Dashboard.
Select Backups.
Use From and To to locate a completed backup.
Read the Restore eligibility message for that row.

If the database is Developer/shared, Backups is intentionally absent.

Recover with a completed backup

When an incident requires recovery:

Stop or buffer application writes.
Establish the latest safe completed backup time from Backup history.
Determine the known data-loss interval between that backup and the incident.
Confirm the backup matches the current provider, region, node count, compute, storage, network mode, development mode, and TigerBeetle version.
Select Restore on the eligible row.
Type the database name exactly.
Select Queue restore.
Wait for the restore to complete and the database to return to Ready.
Verify reads, then reconcile any source-of-truth events that occurred after the backup before resuming writes.

The restored database contains the state represented by the selected completed backup. It does not contain a reconstruction up to an arbitrary later timestamp, and it does not merge post-backup live changes.

Workflow and status behavior

There is no PITR workflow to queue or monitor.

The backup-restore alternative uses a restore job with queued, running, completed, or failed status. Queueing moves the database profile to Provisioning while Parix replaces the provider deployment. Success returns the profile to active; failure can leave it in Error.

Destructive and downtime warning

Backup restore replaces the live database and decommissions its current provider resources before reprovisioning from the selected backup. It causes downtime and discards live database changes after the backup point.

Do not queue restore while applications continue writing. The dashboard's database-name confirmation protects the action but cannot recover writes made after the chosen backup.

Current limitations

No arbitrary timestamp selection.
No continuous recovery log exposed to customers.
No replay-to-transaction or replay-to-event control.
No merge between a restored backup and newer live database state.
No clone-from-backup recovery surface.
Retained artifacts after database deletion do not make a deleted database a normal self-service restore target.
The supported restore path remains subject to provider and exact-shape eligibility; on AWS it currently supports Local NVMe only.

Troubleshooting

I cannot find a PITR control

This is expected. PITR is out of scope in the shipped product; no hidden dashboard route or API parameter enables it.

The required timestamp falls between backups

Choose the latest safe completed backup before the incident, quantify the expected data-loss interval, and use application-owned event records or exports for reconciliation. Do not select a later backup that contains the corruption merely because it is closer in time.

The latest safe backup is ineligible

Read the eligibility message in Backup history. A mismatch in region, node count, compute, storage, network mode, development mode, or TigerBeetle version blocks restore. Incomplete or legacy-metadata backups also cannot be used. Preserve the artifacts and escalate rather than changing the live shape again.

The backup expired

Expired cleanup removes the object, provider snapshot when present, and backup metadata. It cannot be restored from the dashboard. Increase retention for future recovery points and use an approved external export or reconciliation source for the current incident.

Restore failed

Keep writes stopped and follow the failure procedure in Backup and restore. A failed replacement can leave the profile in Error and requires immediate investigation.

Next steps

Configure and test Backup and restore.
Include the absence of PITR in recovery-time and recovery-point objectives.
Use Logs and Metrics to identify the incident window before selecting a backup.