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)
Backup recipe (hand-rolled pg_dump)
Cron’d from anywhere with network access to the DB:
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
appVersionin your IaC andhelm upgradere-creates everything. - Container images - re-pulled from
ghcr.ioon every Pod start.
Restore drill (recommended quarterly)
A backup you haven’t tested isn’t a backup.- Spin up a side-by-side install in a separate namespace pointed at a fresh empty DB.
- Restore your latest backup into that DB.
- Sign in as the break-glass admin. Confirm the cluster list, member roster, and audit log look correct.
- 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 atapp.radarhq.io, that’s our problem - see Cloud Operations for the SaaS DR posture. Self-hosted explicitly delegates this to you.