Backups & Recovery

Automated daily backups, point-in-time recovery, and on-demand manual snapshots for all managed databases.

Diagram of daily base backup plus continuous WAL archiving for point-in-time recovery — Daily snapshots plus WAL archiving let you restore to a specific timestamp, not just the last backup.

Automated daily backups

StackBlaze automatically backs up all managed databases (PostgreSQL, MySQL, MongoDB, Redis with persistence) once per day. Backups run during off-peak hours, typically between 02:00 and 04:00 UTC, to minimize impact on query performance.

All backups are encrypted with AES-256 before leaving the host server. Encrypted snapshots are stored in a separate availability zone from your primary data, providing geographic redundancy within the same region.

Backup retention by plan

Plan	Snapshot retention	PITR window	Cross-region replication
Free	1 day	Not available	No
Starter	3 days	Not available	No
Pro	7 days	7 days	No
Enterprise	30 days	30 days	Yes

Free plan limitation

Free-plan databases retain only the last 24 hours of backups. If you need longer retention or point-in-time recovery, upgrade to Starter or above before you need to restore.

Point-in-time recovery (PITR)

On Pro and Enterprise plans, StackBlaze continuously ships WAL segments (PostgreSQL), binary logs (MySQL), or oplog entries (MongoDB) to object storage. This enables recovery to any specific timestamp within the retention window.

PITR granularity

Database	Log type	Granularity
PostgreSQL	WAL (Write-Ahead Log)	~5 minutes
MySQL	Binary logs	~1 minute
MongoDB	Oplog	~1 minute

Initiating a PITR restore

Navigate to your database in the dashboard, click Backups, then Restore to point in time. Select a target timestamp, then choose:

•Restore to new instance: creates a new database instance at the target timestamp. Your existing database keeps running. Recommended for investigating an incident.
•Restore in-place: replaces the current database with the state at the target timestamp. This is destructive and causes downtime. Only use this when you have no other option.

Best practice

Always restore to a new instance first. Verify the data is correct by querying the restored instance, then update your service's DATABASE_URL to point to it if needed. This gives you a rollback path if the restore doesn't have the data you expect.

Manual backups

You can trigger a manual snapshot at any time, useful before running a risky migration or major data operation.

From the dashboard: navigate to your database → Backups → Take snapshot now. The snapshot is taken immediately and appears in the backup list within a few minutes.

Manual snapshots are retained according to your plan's snapshot retention policy and count toward the same retention limit as automated backups.

Restoring from a snapshot

To restore from a daily snapshot (rather than a specific point in time):

1.Navigate to your database and click Backups.
2.Select the snapshot you want to restore from the list.
3.Click Restore and choose whether to restore to a new instance or in-place.
4.Confirm the restore. StackBlaze will notify you by email when the restore completes (usually 2“15 minutes depending on database size).

Backup encryption

All backups are encrypted at rest using AES-256. Encryption happens on the host before data is written to object storage, unencrypted data never touches the backup storage layer. Encryption keys are managed by StackBlaze and rotated annually.

Enterprise customers can bring their own KMS key (AWS KMS, GCP Cloud KMS, or HashiCorp Vault) for an additional layer of control. Contact support to enable BYOK.

Cross-region backup replication

Enterprise plans include automatic replication of backup snapshots to a secondary region. This provides protection against a full-region outage and enables disaster recovery with an RPO of ~24 hours (or ~5 minutes with PITR replication).

Cross-region backup replication is configured when creating the database or from Settings → Backups → Cross-region replication. Available secondary regions depend on your primary region.

Testing your backups

A backup you've never tested is not a backup. StackBlaze recommends testing restores at least quarterly. Use the Restore to new instance option, run your application's data validation scripts against the restored instance, then delete it.

Example validation script

#!/bin/bash
# Point DATABASE_URL at the restored instance
export DATABASE_URL="postgresql://user:pass@restored-db.internal:5432/dbname"

# Run row count checks
psql $DATABASE_URL -c "SELECT COUNT(*) FROM users;"
psql $DATABASE_URL -c "SELECT COUNT(*) FROM orders WHERE created_at > NOW() - INTERVAL '7 days';"

# Run your app's health check
curl -f https://your-service.internal/health || echo "Health check failed"