Services // Disaster Recovery
A DR plan that's only ever been written, not run, isn't a plan.
I build and test AWS disaster recovery plans out of Delhi NCR real RTO/RPO targets, cross-region backup and replication, and automated failover that's actually been triggered on purpose before it's ever needed for real.
Most DR plans I review look fine on paper. Most of them have never actually been run. Those are two very different levels of confidence.
Start with a DR readiness check →What this actually covers
Planning for the failure that's bigger than a single server
RTO / RPO Planning
How much data can you afford to lose, and how long can you afford to be down answered in real numbers, not "as close to zero as possible," because that answer has a cost attached and most businesses don't actually need the most expensive version.
Cross-Region Backup & Replication
Backups that live somewhere other than the region that just went down, and replication that gets checked for lag instead of assumed to be working. A backup nobody's verified in months is a belief, not a plan.
Automated Failover
Route 53 health checks and failover routing so recovery doesn't depend on someone being awake and available to manually flip a switch during the actual incident.
DR Testing & Runbooks
A written plan is a guess until it's been run. I schedule and run actual DR drills, then write the runbook based on what really happened including the steps that turned out to be missing.
How people usually bring me in
Scoped around real RTO/RPO targets, not a template
DR Readiness Assessment
A look at what would actually happen if your primary region went down today what recovers automatically, what needs a person, and how long that person would realistically take.
DR Plan Implementation
Setting up the replication, backup, and failover mechanics to hit the RTO/RPO targets that actually match your business, not a generic best-practice number.
DR Testing & Runbook Development
You have a DR plan on paper. I run it for real, on a schedule, and turn what actually happens into a runbook your team can follow without me in the room.
How a plan actually gets built
Ending with a real drill, not a document
Set real RTO/RPO targets
Based on what downtime and data loss actually cost your business not a number copied from a compliance template.
Build the recovery path
Backup, replication, and failover mechanics designed to hit those targets, with the cost tradeoffs made explicit upfront.
Run a real drill
Not a tabletop discussion an actual failover, scheduled and controlled, so we find out what breaks while it's not an emergency.
Write the runbook from what happened
Documentation based on the real drill, including the steps that were missing or wrong the first time, not the idealized version from before we tested it.
Questions people actually ask
Before the discovery call
What's the difference between disaster recovery and high availability?
High availability is about surviving a failure with little to no interruption a server or a zone goes down, traffic shifts automatically, nobody notices. Disaster recovery is the plan for something bigger a full region outage, data corruption, an entire environment lost where some recovery time is expected and the goal is getting back up within an agreed window, not staying up through it. Most systems need solid HA as the baseline; DR is the plan for when HA alone isn't enough.
What RTO and RPO should we actually be targeting?
It depends entirely on what an hour of downtime or an hour of lost data actually costs your business which is different for a payments platform than for an internal tool. I won't hand you a generic "4 hours RTO" number without understanding that first, because hitting an aggressive target costs real money in infrastructure and complexity.
Isn't disaster recovery just backups?
Backups are one piece of it, and usually the easy part. The harder part is everything else needed to actually recover restoring in the right order, redirecting traffic, validating the restored environment actually works, and doing all of it within your target window instead of finding out mid-recovery that a step was missing.
How often should a DR plan actually be tested?
At least once or twice a year for most businesses, and after any significant infrastructure change. A DR plan that hasn't been tested since it was written is closer to a hypothesis than a plan I've seen "tested" plans fail on the first real drill because something changed in the six months since it was documented.
What does a DR runbook actually include?
Step-by-step recovery actions in the order they need to happen, who's responsible for each one, how to verify the recovery actually worked, and the rollback if the failover itself goes wrong. Written for whoever's on call during the actual incident, not for a compliance binder.
Is a formal DR plan overkill for a small company?
Sometimes, yes a small team with a simple stack and no regulatory requirement might genuinely be fine with solid backups and a documented manual recovery process rather than a full automated failover setup. I'd rather tell you that honestly during the assessment than sell you more infrastructure than your risk actually justifies.
Find out if your DR plan actually works before you need it to.
Most gaps only show up once someone actually tries to run the recovery for real.
Get in touch →