Disaster Recovery
Per-organization automated backups on KubeWatch Cloud, with a built-in restore test on every run.
On KubeWatch Cloud, each organization has its own dedicated database (not a database shared across every tenant), which is what makes a customer-facing, per-organization backup control possible. Disaster Recovery is available on the Pro and Enterprise plans.
What it does
On the schedule you configure (24 hours by default):
- Runs a database dump scoped to your organization's own database only.
- Pushes it to every destination you've configured.
- Restores it into a scratch database to verify it actually works, then drops the scratch database.
- Records the result per destination, plus the restore-test outcome.
You can also trigger a backup immediately from the Disaster Recovery page without waiting for the schedule.
Enabling it
Open Disaster Recovery in the sidebar (under the Platform section). If your plan doesn't include it, you'll see an upgrade prompt instead of the controls below. See Plans & Pricing.
- Add at least one destination (S3, SFTP, webhook, or Azure Blob). These are the same four kinds and fields as the self-hosted version. See Disaster Recovery for the exact fields each one needs. Credentials are entered once when you add the destination and are never shown again in the UI.
- Turn on automatic backups and set the interval (in hours, 24 by default).
- Set retention (30 days by default, or Forever to disable pruning). Every time a backup runs, anything older than the retention window is deleted from every destination it was pushed to (S3 object, SFTP file, Azure blob) as well as from the backup history. A webhook destination has no generic delete API, so old webhook deliveries aren't retroactively removable.
- Optionally click Run backup now to trigger one immediately, independent of the schedule.
Viewing backup history
The same page lists every backup that's run: when, how it was triggered (manual or scheduled), size, per-destination delivery status, and the restore-test result.
Limitations (this release)
- Only your organization's own database is covered. This does not back up anything outside KubeWatch itself.
- Backups currently run the same way as self-hosted's Docker Compose path (an ephemeral container alongside the database) rather than as a Kubernetes Job. This only matters if you're curious about internals. The destinations, scheduling, and restore-test behavior are identical either way.