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

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 but not part of this backup product. See Object Storage.
• Redpanda — durability is built into the broker; design retention deliberately. See Redpanda.