Backups and Restores

PostgreSQL, Valkey, and ClickHouse all support a backup and restore workflow. The shape is the same for all three, with service-specific commands where it helps.

What backups Watasu offers

Two flavors:

• manual backups — you trigger them, on demand
• scheduled backups — Watasu runs them on a recurring cadence on supported plans

Entry-tier plans typically only support manual backups. Higher tiers add scheduled backups by default. The plan catalog in Add-on Plans tells you which is which.

Restore is not in-place

Restoring an add-on creates a replacement add-on from the backup, then you promote the replacement into the original’s attachment role.

This is intentionally safer than overwriting in place. You can validate the restored copy before flipping the app to it, and the original is still around if anything goes wrong.

The two-step model:

watasu addons:restore my-database backup-id-or-file --name my-database-restored
# … verify the restored add-on …
watasu addons:promote my-database-restored

After promotion, the app’s DATABASE_URL (or whatever the env var is) points at the restored copy.

Service-specific examples

PostgreSQL

# capture a manual backup
watasu pg:backups:capture --app my-app

# list available backups
watasu pg:backups --app my-app

# restore from a managed backup
watasu pg:backups:restore b101 DATABASE_URL --app my-app --name db-restored

# or restore from a local dump file
watasu pg:backups:restore ./production.dump DATABASE_URL --app my-app --name db-restored

# promote when ready
watasu pg:promote db-restored --app my-app

Valkey

watasu addons:backups:capture my-cache
watasu addons:backups my-cache
watasu addons:restore my-cache ./backup.rdb --name my-cache-restored
watasu addons:promote my-cache-restored

ClickHouse

watasu addons:backups:capture analytics-db
watasu addons:backups analytics-db
watasu addons:restore analytics-db ./warehouse-backup.zip --name analytics-db-restored
watasu addons:promote analytics-db-restored

Restoring from a local file

All three services accept an uploaded backup file in place of a managed backup id (up to 5 GiB):

Service	Accepted formats
PostgreSQL	.backup, .dump, .sql, .sql.gz, .tar
Valkey	.rdb
ClickHouse	.zip, .tar, .tgz, .tar.gz

When to capture a manual backup

• before any risky schema migration
• before a destructive data operation
• before a major dependency upgrade that touches the database
• before scheduled maintenance windows

The few seconds it takes is the cheapest insurance you’ll ever buy.

Test restores before you need them

A backup that’s never been restored is a hopeful guess. Periodically:

1. restore a recent backup into a replacement add-on
2. attach it to a scratch app or run validation queries
3. destroy the replacement when done

Doing this once a quarter beats discovering during an incident that your dump format changed.

What’s not in this flow

• Object Storage — durable by design (and geo-replicated on Premium tiers), but not part of this backup product. If your app deletes the wrong object, durability won’t bring it back. Design soft-deletes or versioning at the application level if you need that. See Object Storage.
• Redpanda — durability is built into the broker via replication factor and acks. There’s no platform-managed backup/restore API for Redpanda; design topic retention and downstream replay deliberately. See Redpanda.
• Logs, Metrics, Traces — these are observability data, not backup products. There’s no user-facing backup or restore API for them. If you deprovision a Logs/Metrics/Traces add-on, the historical data is gone. Plan retention windows accordingly, and use Object Storage for any audit trail you need to keep beyond the observability retention window.