Skip to main content

The TL;DR

Back up Postgres. The chart itself is stateless.

What lives where

The control plane holds no customer cluster data. Helm catalog / package state, audit findings, topology - all of that lives in the customer’s own etcd / Radar’s per-cluster cache. Restoring the control plane means restoring its Postgres + redeploying the chart; tunnels reconnect within seconds.

Backup recipe (managed Postgres)

Use whatever your provider offers - RDS automated backups, Cloud SQL exports, Azure Flexible Server PITR. Set retention to your compliance requirement.

Backup recipe (CloudNativePG)

CNPG handles the rest - snapshots land in the object store you configured for the cluster.

Backup recipe (hand-rolled pg_dump)

Cron’d from anywhere with network access to the DB:
Restore:

What you DON’T need to back up

  • helm get values radar-hub --namespace radar-hub - check this into your IaC repo and you can re-derive the install. (Strip secrets first - those should already be in your Secret manager.)
  • The Helm chart itself - we publish it on a versioned repo; pin the appVersion in your IaC and helm upgrade re-creates everything.
  • Container images - re-pulled from ghcr.io on every Pod start.
A backup you haven’t tested isn’t a backup.
  1. Spin up a side-by-side install in a separate namespace pointed at a fresh empty DB.
  2. Restore your latest backup into that DB.
  3. Sign in as the break-glass admin. Confirm the cluster list, member roster, and audit log look correct.
  4. Tear down. Net result: confidence + a dated record that the procedure works.

What’s NOT backed up by Skyhook

In a self-hosted install Skyhook has no access to your data. Your Postgres backups, your problem. If you’re running the hosted Cloud at app.radarhq.io, that’s our problem - see Cloud Operations for the SaaS DR posture. Self-hosted explicitly delegates this to you.