case study · client delivery · 2026

A disaster recovery plan built around the business, not the tools

A financial services client ran critical applications on Kubernetes but had no clear way to recover them if a cluster or site failed. I designed a tiered disaster recovery approach that matched each application's protection to its business importance, with immutable backups, a second recovery location and a documented runbook.

CLIENT

Financial services enterprise

ROLE

DR workshops, design and runbook

EMPLOYER

FABS

Backups retained immutably for 30 days.

The client's applications had moved onto Kubernetes faster than its recovery plans. Some data was backed up, but there was no agreed answer to two basic questions: how much data could the business afford to lose, and how quickly did each application need to come back? Without those answers, every application was being treated the same way, which meant over-spending on systems that didn't need it while under-protecting the ones that did. For a regulated business, it was also a gap auditors would eventually ask about.

1. 1tiered by impact
   protection matched to what an outage would cost
2. 2whole applications
   config, secrets and data backed up together
3. 3ransomware-proof copies
   immutable and kept off the production cluster
4. 4critical apps first
   restore in priority order, following the runbook

1. 01Started with the business, not the tools. Ran workshops with application owners to agree how much data loss and downtime each system could tolerate, then set RPO and RTO targets per tier.
2. 02Classified every application. Grouped workloads into three tiers, so the tightest and most expensive protection went only where it was needed.
3. 03Designed application-aware backups. Backup policies captured each application as a whole: its Kubernetes resources, configuration, secrets and persistent volumes, on a schedule matched to its tier.
4. 04Protected the backups themselves. Copies were stored off-cluster in object storage with immutability enabled, so an attacker who reached the cluster couldn't delete or encrypt the backups.
5. 05Planned recovery to a second location. Defined how applications would be restored onto a separate cluster if the primary one was lost.
6. 06Wrote the runbook. Documented step-by-step recovery procedures, in priority order by tier, so the client's own team could run a recovery under pressure.
7. 07Built in regular testing. Recommended scheduled recovery tests for each tier, so the targets are checked against reality rather than assumed.

Protecting everything to a 15-minute RPO sounds safe, but it multiplies storage, bandwidth and licensing costs across systems that don't need it. Tiering puts the budget where an outage would actually hurt. This is where my accounting background is useful: DR is ultimately a cost and risk decision, and the business should be able to see what each level of protection costs and what it buys.