When it comes to backup and disaster recovery, there are several ways to snapshot applications and app data in Kubernetes. Let’s take a closer look at each approach for pros and cons.
etcd backup
Exporting kubernetes manifests manually
Storing in all kubernetes manifests in Git before applying
This is a preferred approach for repeatable deployments and backing up manifests but has some edge cases. let’s discuss the edge cases
Note:
- In all the above cases application data and k8s manifests mapping need to be tracked
- Some of the attributes like image SHA (which is a true representation of immutability on a docker image) are only avaialble (in most cases) after application is deployed. All the methods above do not capture such attributes of a backup
Export and backup all objects in a namespace
Using tools like Velero to export and backup all objects in a namespace is by far my most preferred way to backup and restore Kubernetes workloads.
Why it works:
This method does have some drawbacks:
Using CAPE by Biqmind
It was with all this in mind that we developed the disaster recovery component for CAPE, our tool for advanced K8s multi-cluster application & data management functionality. What does CAPE do then?
I presented a webinar where I delve deeper about using Velero for disaster recovery and data migration – check it out on our YouTube channel.
About the Author

Chakradhar Jonagam
Biqmind Head Software Architect and CNCF Ambassador
Chak has over 10 years of experience helping customers across the US and APAC unlock the value of cloud and related technologies for their businesses. Previously at Red Hat as a Senior Solutions Architect, Emerging Technologies practice, he worked with enterprise clients across the region on their solutions architectures and technical solution implementation strategies. Chak is also a Cloud Native Compute Foundation(CNCF) ambassador and passionate community advocate. He has presented at Devnation Federal, Red Hat Summit and organized meetups around the world.