Short answer: Choose Kubernetes backup software only after defining cluster and namespace resources, custom resources and definitions, admission and policy objects, secrets, persistent volumes, databases, application consistency, cluster-scoped dependencies, external cloud resources, GitOps ownership, encryption, backup isolation, restore order, clean-cluster and cross-region recovery, scale, monitoring, cost, and export. Kubernetes documentation notes that etcd contains cluster configuration and should be backed up regularly, while persistent storage and application recovery require separate planning; a product must prove the complete application, not just resource capture.
A namespace backup can omit cluster-scoped objects, storage snapshots, encryption keys, webhooks, operators, DNS, load balancers, identities, or managed services. A restored manifest set is not a running application.
Use the same stateful application, CRDs, operators, secrets, policies, external services, failed snapshots, version change, regional loss, and clean target cluster for every finalist. Compare application acceptance and recovery time, not object counts.
Define Cluster And Application Coverage
Inventory namespaces, cluster-scoped resources, CRDs, custom resources, operators, RBAC, policies, admission webhooks, secrets, service accounts, network rules, storage classes, persistent volumes, snapshots, charts, GitOps sources, and external dependencies. Mark discovered, protected, recreated, and unsupported items.
Seed labels, finalizers, owners, generated objects, deleted namespaces, dynamically provisioned volumes, and orphan resources. Reconcile source and backup inventories with documented exclusions.
Separate Control-Plane, Resource, And Data Recovery
Clarify managed versus self-managed control plane and whether etcd backup is customer responsibility. Kubernetes documentation identifies etcd as the store for cluster configuration; test its protection separately from application-level resource export.
Map persistent data to CSI snapshots, file or application backup, database-native backup, replication, and external services. Define which method supplies each recovery point.
Prove Application Consistency
Test pre- and post-hooks, quiescing, database checkpoints, grouped volume snapshots, timeout, hook failure, partial snapshot, resumed writes, and crash-consistent recovery. Kubernetes volume group snapshots can provide crash-consistent recovery for supported CSI drivers, but application consistency still needs validation.
Restore transactions, indexes, queues, object relationships, and application health using workload-specific checks. Record data loss and manual repair.
Protect Backup Credentials And Storage
Review service accounts, RBAC, cloud permissions, snapshot rights, storage accounts, encryption, keys, immutable retention, cross-account or cross-project copies, administrator separation, support access, audit, and emergency credentials. Etcd and secret-bearing backups require high protection.
Test production-admin compromise, backup-account loss, key unavailability, retention reduction, object deletion, and independent alerting. Define who can restore privileged cluster objects.
Restore Dependencies In The Right Order
Document target cluster version, APIs, CRDs, operators, storage classes, secrets and keys, policies, webhooks, namespaces, persistent data, workloads, services, ingress, DNS, certificates, and external resources. Require dependency planning and conflict handling.
Test original, alternate namespace, alternate cluster, alternate storage class, and cross-region restore plus existing-object merge, rename, skip, overwrite, and rollback behavior.
Recover Into A Clean Cluster
Build an empty target under documented prerequisites and recover a representative application without hidden production dependencies. Exercise unavailable source cluster, failed region, missing plugin, changed API version, incompatible CSI driver, throttling, and partial recovery.
Measure RPO, RTO, operator time, manual steps, data validation, security validation, DNS and traffic cutover, rollback, and evidence. Run an application-owner acceptance test.
Model Operations, Cost, And Exit
Price clusters, nodes, namespaces, resource count, protected capacity, snapshot and object storage, change rate, regions, retention, restores, egress, support, and plugins. Include upgrade tests, failed-job investigation, recovery drills, and infrastructure prerequisites.
Export backup data or documented open formats, manifests, metadata, snapshot references, policies, schedules, hooks, credentials mapping, job history, and audit logs. Test restore without the vendor control plane, uninstall, final snapshots, deletion, and transition.
Pilot From Stateful Workload To Clean Cluster
Prove Complete Protection
Seed The Dependency Graph
Include cluster and namespace resources, CRDs, operators, policies, secrets, volumes, databases, GitOps, and external services.
Validate Consistency
Test hooks, grouped snapshots, database checkpoints, partial failure, resumed writes, transactions, queues, and application health.
Prove Disaster Recovery
Restore In A Clean Target
Recover through version, API, storage, region, identity and external-service differences with documented order and conflicts.
Measure Business Acceptance
Record RPO, RTO, manual effort, data and security checks, traffic cutover, rollback, evidence, cost and portability.
Kubernetes Backup Buying Scorecard
| Buying area | What to confirm | Why it matters |
|---|---|---|
| Coverage | Cluster and namespaced objects, CRDs, operators, policies, secrets, volumes, GitOps, external services, and exclusions | Defines the complete application |
| Recovery layers | Etcd, resources, CSI snapshots, file and database backup, replication, and managed-control responsibilities | Prevents one-method assumptions |
| Consistency | Hooks, grouped snapshots, checkpoints, timeouts, partial failure, transaction and application validation | Proves usable state |
| Security | RBAC, cloud rights, isolation, encryption, keys, immutability, admin separation, support, audit, and recovery roles | Protects privileged backups |
| Disaster restore | Dependency order, clean cluster, versions, APIs, storage, regions, conflicts, RPO, RTO, cutover, and rollback | Tests real recovery |
| Cost and exit | All capacity and operation meters, drills, plugins, open formats, vendor-independent restore, uninstall, and deletion | Reveals TCO and lock-in |
Questions To Ask Before Approval
- Which cluster and namespace resources, volumes, databases, external services, and metadata are unsupported?
- Who owns etcd, application-resource, storage, and database recovery in each cluster type?
- How are application-consistent recovery points created and failures handled?
- Can a compromised cluster administrator delete backups, keys, retention, and alerts?
- What dependency order and conflict rules govern restore?
- Can the product recover into a clean cluster with changed region, version, API, and storage?
- What RPO, RTO, manual effort, validation, cutover, and rollback did the pilot measure?
- Can backups and policies be restored or migrated without the vendor control plane?
Buying Red Flags
The vendor equates a successful resource export with recovery of persistent state, external services, and application behavior.
The pilot restores into the same healthy cluster and avoids clean-cluster, region, version, storage, and identity differences.
Backup formats, snapshot references, schedules, hooks, policies, and audit history cannot be exported or used after termination.
Source Links
- Kubernetes production environment guidance on etcd backup
- Kubernetes operating etcd clusters and restore guidance
- Kubernetes persistent volume concepts
- Kubernetes volume group snapshot recovery overview
FAQ
Is etcd backup enough?
No. It can protect cluster configuration for applicable self-managed control planes, but persistent application data, external services, secrets, and recovery order require additional planning.
Are storage snapshots application-consistent?
Not automatically. Crash-consistent or grouped snapshots may still require application quiescing, database checkpoints, hooks, and recovery validation.
What should a clean-cluster test include?
Versions, APIs, CRDs, operators, policies, identities, storage classes, data, workloads, ingress, DNS, certificates, external services, cutover, and rollback.
How should secrets be protected?
Use least privilege, encryption and key controls, isolated storage, administrator separation, immutable retention, protected audit, and tightly governed restore roles.
What is the best acceptance test?
Application owners should validate transactions, data, permissions, security policies, dependencies, performance, and business workflows after measured recovery.
What must be portable?
Backup data or open formats, manifests, metadata, snapshot mapping, schedules, policies, hooks, job and audit history, and restore documentation.
Related Software Buyer Guide Guides
- IT asset management software checklist
- Privacy management software checklist
- Workflow automation software checklist
Kubernetes backup is ready to buy when cluster configuration, application resources, persistent state, dependencies, security, clean-target recovery, operations, and exit are all proven together.