Identify the layers to protect
Kubernetes resources, persistent volume data, databases, images and external service configuration are different layers. A Git repository may protect manifests but not runtime data. Without registry access or DNS, an application can fail even with correct definitions. Identify a restoration method and owner for every layer.
Database consistency
Copying a disk does not always produce an application-consistent database backup. Assess native database backups, transaction logs and restoration order. Check the scope of storage snapshots and whether they are independent copies. A snapshot on the same storage system may not replace a separate recovery copy if that system is lost.
Rehearse restoration order
The cluster and required add-ons may come first, followed by secrets, storage and application resources; actual order depends on dependencies. Encrypt secrets and restrict access. In a test cluster, check connectivity, data correctness and core business transactions. Restoring a namespace does not mean the whole application has recovered.
Design recovery alongside operations
Backup planning should not be detached from deployment. A new stateful service, a storage class change or an application version can affect the recovery plan. Consider F2Cloud DevOps, Backup and Recovery together to clarify data ownership, platform ownership and acceptance criteria. Supported tools and versions are verified during discovery.
Pre-decision checklist
- List manifests, secrets and persistent data separately.
- Include external dependencies in the test.
- End the test by verifying a business transaction.