What does application backup cover?
Application-level protection captures manifests, configurations, secrets and persistent volume data in selected namespaces under a policy. The goal is restoring the application to a defined recovery point — on the same or a compatible cluster. Namespace selection and data consistency are part of the design; 'everything is backed up' is never assumed.
Cluster recovery is a separate scenario
The control plane, etcd state, cluster configuration and operators are handled at platform level, outside application backup scope. Losing an entire cluster requires a different runbook, different dependencies and usually a different RTO target. Confusing these two scenarios is one of the most common planning mistakes during an actual disaster.
Persistent data is protected separately
Persistent volume snapshots can offer fast rollback on the storage system but may share the same failure domain. An independent backup copy means data held in a separate environment under a retention policy. For stateful applications with databases, consistency is supported by application-aware backup steps; a plain file copy may not be enough.
Recovery is tested at application level
A restore test brings the application up in a separate namespace or test cluster. Routes, services, configmaps and data integrity are validated together. Under F2Cloud scope, backup design and test frequency for OpenShift workloads are defined in the proposal according to the application's criticality.
Pre-decision checklist
- Clarify whether the scope is the application or the cluster.
- List your stateful applications and consistency needs.
- Have the restore-test environment written into the proposal.