Restore policy changes the recovered result
Backup for GKE restores selected Kubernetes resources and supported volume data according to a restore plan. The plan decides what happens when resources already exist in the target and how persistent volume data is handled. Those choices can produce very different outcomes from the same backup.
A restore that skips an existing resource might leave an old configuration running. A restore configured without volume data can produce claims that do not contain the expected application records. Custom resources may also depend on an operator or another resource type. Recovery must therefore define both the infrastructure behavior and the business result that proves success.
Prepare an isolated target cluster or approved recovery environment, a specific backup identifier, application ownership, and a written list of external dependencies. Confirm which data is covered by volume backup and which lives in services outside the cluster. Keep the rehearsal away from production write endpoints and customer notification systems.
Make the plan explicit
- Inspect the restore plan and selected backup before executing anything. Record the namespace or ProtectedApplication selection, target cluster, resource conflict mode, and volume-data policy. Decide whether existing target resources should cause failure, be skipped, or be replaced; do not accept a destructive conflict mode without understanding the target contents.
- Inventory application consistency requirements. Where the application needs quiescing, dumps, or coordinated components, review supported ProtectedApplication strategies and hooks. A filesystem-level capture should not be silently described as a transaction-consistent database backup.
- Check restore dependencies. Ensure required operators and cluster capabilities exist. Use supported GroupKind ordering when custom resources need a defined relationship. Ordering resource creation does not prove the operator has finished reconciling or the application is ready, so include readiness checks afterward.
- Run the approved rehearsal and inspect individual restore results. Use
kubectl get pods,pvc -n NAMESPACEand application-specific read-only checks in the isolated target. Compare recovered records and configuration with the chosen backup point rather than simply counting running Pods.
Illustrative scenario
A fictional ordering platform restores into a recovery cluster that already contains an older ConfigMap and an empty persistent volume. A permissive merge policy skips a conflict, and the workload starts with unexpected configuration. The team revises the rehearsal to fail on unplanned conflicts and explicitly restore new volumes from backup data. A sample order lookup then verifies that the expected business state, rather than an empty but healthy application, has returned.
| Observation | Restore boundary | Correction |
|---|---|---|
| Pods run with old configuration | Resource conflict handling | Choose and test an intentional conflict mode |
| PVC exists but records are absent | Volume-data policy | Restore the required backed-up data |
| Custom resources fail early | Operator and GroupKind dependencies | Install prerequisites and define ordering |
| Database starts with consistency errors | Capture method and application hooks | Use an application-aware backup strategy |
Verify recovery acceptance
Check record counts only where meaningful, then inspect specific representative records and a harmless business workflow. Confirm application credentials, internal DNS, and external dependency routing. Verify that the restored environment cannot accidentally send production messages. Measure elapsed recovery time from the agreed starting event, including manual decisions and application validation. Record the actual recoverable data point.
Operating procedure
Schedule restore rehearsals after operator, storage, or application topology changes. Monitor backup failures, backup age, and restore-plan drift. Keep conflict handling and volume policy in the recovery record with the application owner. Retain evidence from the last successful business acceptance check; a backup-success dashboard alone does not establish a usable recovery path.
Explore Clouvenix backup disaster recovery for implementation and operational handover.