Kubernetes backup and disaster recovery
Protect applications and data on Kubernetes and OpenShift with application-aware backups, replication to a second site and failover you have rehearsed, against recovery targets the business has agreed.
Recovery you have tested, not recovery you hope for
Kubernetes restarts failed containers and replaces failed nodes on its own. It does not protect you from losing a data centre, deleting the wrong namespace, corrupted data or ransomware. For that you need backups that capture whole applications, copies of the data at a second site, and a failover that people have practised.
We design and build disaster recovery for Kubernetes and OpenShift around two numbers the business agrees: how much data it can afford to lose, the recovery point objective, and how long it can be down, the recovery time objective. Then we prove them with regular drills, which regulators such as Bangladesh Bank expect for critical systems.
When it fits
01
Backups cover servers, not applications
You back up volumes or virtual machines, but not the Kubernetes objects that make an application run.
02
There is a DR site but no plan
A second data centre exists, but failing over to it is a manual, untested exercise.
03
Auditors ask for drills
You are asked for recovery objectives, test results and evidence of regular drills.
04
Ransomware is a worry
You need copies that attackers cannot encrypt or delete, kept apart from production.
What we do
Application-aware backups
Back up namespaces with their configuration, secrets and volumes together, using Velero or OpenShift API for Data Protection.
Storage replication
Copy persistent volumes to a second site with your storage arrays or OpenShift Data Foundation, synchronously or asynchronously.
Second-site clusters
A standby cluster at the DR site, or both sites serving traffic, depending on cost and recovery targets.
Traffic failover
Global load balancing and DNS that move users to the surviving site.
Immutable copies
Backups kept in a third location on immutable object storage, out of reach of ransomware.
Drills and runbooks
Step-by-step runbooks, and failover and failback drills on a schedule, with written results.
Failover
When a site fails, traffic moves and the data is waiting
Data is copied to the DR site continuously, and backups go to a third location. If the primary site fails, traffic switches to the DR cluster, which starts the applications on the latest copy of the data.
- Live traffic
- Users are served by the primary site, and by the DR site after a failover.
- Storage replication
- Volumes are copied to the DR site continuously, so little or no data is lost.
- Backups in a third location
- Application backups on immutable storage, for deletions, corruption and ransomware.
- Site failure
- Detected by monitoring, then handled by a rehearsed runbook, automatically or on approval.
How we build disaster recovery
01
Agree targets
Classify the applications and agree recovery point and recovery time objectives with the business.
02
Design
Choose backup, replication and site layout for each class of application, and weigh the cost against the risk.
03
Build
Set up backups, replication, the DR cluster and traffic failover, and write the runbooks.
04
Prove
Restore applications and fail over in planned drills, record the results and close the gaps.
What you get
- Recovery objectives agreed for each class of application
- Backups of namespaces, configuration and volumes
- Replication and a DR cluster at your second site
- Immutable backup copies in a third location
- Failover and failback runbooks
- Drill reports with measured recovery times
Platforms and tools
- Velero
- OpenShift API for Data Protection
- OpenShift Data Foundation
- Metro-DR and Regional-DR
- Advanced Cluster Management
- Hitachi storage replication
- NetApp SnapMirror
- Pure Storage replication
- Portworx
- S3 Object Lock
- F5 BIG-IP DNS
- ExternalDNS
Questions about disaster recovery
Isn't Kubernetes highly available already?
Within a site, yes: it restarts containers and replaces failed nodes. It doesn't protect against losing the site, deleting the wrong thing or corrupted data. That takes backups and a second site.
Active-active or active-passive?
Active-active serves users from both sites and recovers fastest, but every application and database must support it. Active-passive keeps a standby at the DR site and costs less. Many clients mix the two, application by application.
How often should we test failover?
Whole-site drills at least once or twice a year, and more often for individual applications. Your regulator or auditors may set a minimum, and we schedule drills to meet it.
Can the DR site be in the cloud?
Yes, if your data rules allow copies there. A cloud cluster can stand by for an on-premises platform, which avoids buying a second set of hardware that sits idle.
Do backups cover databases running on Kubernetes?
Yes, with care. We use the database's own backup tools or consistent snapshots, so a restore gives a working database rather than a half-written copy.
Know that you can recover
Tell us which systems matter most and what your regulator expects. We'll propose recovery targets, a design and a first drill.