Backup & Restore

Kipper includes automatic backup and restore powered by Velero. Every cluster gets daily backups of all Kubernetes resources and persistent volume data (databases, file storage) out of the box.

There are two storage modes:

• In-cluster MinIO (default). Zero configuration, no external account required. Backups live on Longhorn-backed storage on the same host as the cluster.
• External S3-compatible storage (AWS S3, Cloudflare R2, self-hosted MinIO, B2, Wasabi, Spaces). Backups live off-cluster and survive a kip cluster uninstall or a host failure.

For any cluster that holds data you cannot afford to lose, configure external storage at install time. See External backup storage on the installation page for the flags.

Automatic backups

A daily backup runs at 3:00 AM and is retained for 7 days. This is configured during kip install and runs automatically.

kip backup schedules

  NAME           SCHEDULE       STATUS    LAST BACKUP
  daily-full     0 3 * * *      Enabled   2026-03-18T03:00:00Z

Manual backups

Back up everything

kip backup create

Back up a specific project

kip backup create --project yourr-name --environment test

Back up with a custom name

kip backup create pre-migration --project yourr-name

List backups

kip backup list

  NAME                          STATUS       NAMESPACES          CREATED
  daily-full-20260318030000     Completed    all                 2026-03-18 03:00
  pre-migration                 Completed    yourr-name-test     2026-03-18 14:30
  manual-20260318-153000        Completed    all                 2026-03-18 15:30

Restoring from a backup

Restore to the same namespace

kip backup restore pre-migration

Restore to a different namespace

Useful for testing a restore without affecting the live environment:

kip backup restore pre-migration --namespace-mapping yourr-name-test:yourr-name-restored

What gets backed up

Resource	Backed up?	How
Deployments, Services, Ingresses	Yes	Kubernetes resource definitions
ConfigMaps, Secrets	Yes	Kubernetes resource definitions
Environment variables and app secrets	Yes	Stored as Kubernetes Secrets
PostgreSQL data	Yes	PVC data via Kopia file-system backup
Redis data	Yes	PVC data via Kopia file-system backup
Longhorn volumes	Yes	Full file-system backup of volume contents

Architecture

In-cluster MinIO (default)

• Velero orchestrates backups and restores
• Node Agent (DaemonSet) reads actual file data from persistent volumes using Kopia
• MinIO provides S3-compatible storage inside the cluster
• Longhorn provides durable storage for MinIO itself

External S3-compatible storage

• External bucket lives in AWS S3, Cloudflare R2, self-hosted MinIO, B2, Wasabi, DigitalOcean Spaces, or any other S3-compatible service
• cloud-credentials Secret in the velero namespace holds the access key, written from the credentials file you passed at install time
• The Velero HelmChart references the Secret by name; the credentials never appear in any HelmChart CR or kubectl-apply output
• Local ~/.kip/config.yaml records mode + bucket + region + endpoint, never the keys

To rotate keys later, run kip install again with the updated credentials file pointing at the same host. The install path is idempotent and replaces the Secret in place.

Retention

Default retention is 7 days (168h). To create a backup with custom retention:

kip backup create --ttl 720h  # 30 days

Limitations

• In-cluster mode: backups are stored inside the cluster, so a host loss or kip cluster uninstall takes the backups with it. Configure external backup storage for clusters that hold data you care about.
• Database backups capture the file-system state of the PVC. For the most consistent database backups, consider running pg_dump before the backup or using the database's native backup tools alongside Velero.
• Backup storage mode is chosen at install time. To switch a cluster from in-cluster to external (or between providers), back up first, uninstall, reinstall with the new flags, then restore.