Kubernetes Backup Setup and Audit with Kasten K10

Imagine: a production Kubernetes cluster fails, and you're losing critical PostgreSQL data — backups exist, but recovery takes hours and you're unsure about consistency. Kasten K10 solves this with application-consistent snapshots and automated policies. We integrate K10 into your infrastructure for enterprise backup, restore, and migration. This is not just a Velero alternative — it's a full data management platform with a UI, policy engine, and built-in database support. K10 accelerates recovery by 2x through automation, and downtime cost savings reach 40% compared to manual scripts.

It's installed in the cluster as a Helm release, occupying a dedicated kasten-io namespace, and managed either via web interface or through Kubernetes resources (Policy, BackupAction, RestoreAction).

Where K10 beats Velero

K10 provides application-consistent snapshots out of the box for PostgreSQL, MySQL, MongoDB using Blueprint — custom hooks that K10 runs before the snapshot. Velero also supports pre/post hooks, but Blueprint in K10 are reusable CRD resources, not inline annotations on each pod. Blueprints reduce database backup setup time by 5x compared to manually writing pre/post hooks in Velero.

Example Blueprint for PostgreSQL flush:

---
apiVersion: cr.kanister.io/v1alpha1
kind: Blueprint
metadata:
  name: postgres-hooks
  namespace: kasten-io
actions:
  backupPrehook:
    phases:
      - func: KubeExec
        name: pgFlush
        args:
          namespace: "{{ .Deployment.Namespace }}"
          pod: "{{ index .Deployment.Pods 0 }}"
          containers: ["postgres"]
          command: ["psql", "-U", "postgres", "-c", "CHECKPOINT;"]
---

K10 picks up the Blueprint by label on the Deployment — no podSpec annotations needed.

K10's weak point is resource consumption. On a cluster with 50+ namespaces, the K10 catalog and API server consume noticeably more than Velero. In managed clusters with limited control planes, this can be problematic. The second downside is licensing: K10 is free up to 10 nodes, then paid. That changes the solution's economics.

Typical installation issues

The most common startup mistake is installing K10 without first checking that the StorageClass supports VolumeSnapshot. K10, like Velero, depends on the CSI snapshot API. kubectl get volumesnapshotclass — if empty, file-based backup via Kopia must be enabled explicitly with helm install --set kanister.enabled=true.

Second issue: K10 tries to auto-discover applications via label selectors. Applications without standard labels (app.kubernetes.io/name, app.kubernetes.io/instance) don't appear in auto-discovery. If deployments lack these labels, the K10 UI shows the namespace as unstructured, and policies must be assigned manually.

Third — configuring a Location Profile for object storage. K10 uses its own Profile CR format, not the standard Velero BackupStorageLocation. When migrating from Velero, these are not interchangeable — backups are incompatible.

How K10 ensures backup consistency for databases

Thanks to Blueprint hooks, K10 executes commands in containers before taking the snapshot: for PostgreSQL it's CHECKPOINT, for MongoDB — fsyncLock. This ensures data on disk is consistent. After the snapshot, a post-hook executes to unlock (e.g., fsyncUnlock). All this is automated by policies.

Policies and schedules

In K10, a backup policy is a Policy CR or UI configuration. A typical production policy:

• Snapshot every hour, retention 24 snapshots
• Export to S3 daily, retention 30 days
• Export to offsite (another region) weekly, retention 12 weeks

K10 supports Kanister transforms during restore — you can change StorageClass, namespace, image registry directly in the restore policy. This solves the cross-cluster restore problem that requires manual ConfigMap in Velero.

How to handle automatic application discovery?

If your applications lack standard labels, add them: app.kubernetes.io/name and app.kubernetes.io/instance. K10 uses these labels for grouping and display. You can also manually create a Policy for selected namespaces, but auto-discovery speeds up setup.

Work process

1. Cluster audit: check CSI driver, VolumeSnapshot API, node count (license limit), workload labels.
2. Installation: via Helm — configure ingress for K10 Dashboard, OIDC authentication (recommended — K10 Dashboard should not be exposed without auth), RBAC for developers (read-only access to backup status).
3. Storage setup: create Location Profiles for primary and offsite storage.
4. Blueprint creation: for stateful applications (databases, queues).
5. Policy configuration: for each criticality level.
6. Test restore: in an isolated namespace to verify.

Cost is calculated individually after infrastructure audit. Request a consultation — we'll assess your project and offer the best turnkey solution. Get a detailed implementation plan with quality guarantee.

What's included

• Documentation: policy configuration, restore schemas, developer runbook.
• Access: RBAC setup and integration with OIDC/SAML.
• Training: workshop for your team on using the K10 Dashboard.
• Support: assistance for one month after deployment.

For an in-depth understanding of the VolumeSnapshot API, refer to the official Kubernetes documentation. Contact us — our engineers can help set up reliable backup for your cluster.