Why DR Planning Cannot Wait
Indian enterprises are increasingly dependent on cloud infrastructure for revenue-critical operations. Yet many organizations treat disaster recovery as a future project -- something to implement "once we are more mature."
The reality: outages happen. AWS Mumbai had notable disruptions in 2023 and 2024. Azure and GCP have experienced India-region incidents. And natural disasters, ransomware attacks, and human errors do not wait for your DR plan to be ready.
This guide covers practical DR strategies for Indian enterprises, balancing recovery objectives with budget constraints.
DR Fundamentals
Recovery Time Objective (RTO)
How long can your business tolerate an outage? This varies by system: - Payment processing: Minutes (RTO < 15 min) - Customer-facing applications: 1-4 hours - Internal tools: 4-24 hours - Batch processing: 24-72 hours
Recovery Point Objective (RPO)
How much data loss is acceptable? - Transactional databases: Zero to seconds (synchronous replication) - Application data: Minutes (asynchronous replication) - Analytics data: Hours (periodic snapshots) - Archival data: Days (daily backups)
Cost-Recovery Tradeoff
Tighter RTO and RPO targets cost exponentially more. A 15-minute RTO requires hot standby infrastructure running continuously. A 4-hour RTO can use warm standby with smaller pre-provisioned capacity. A 24-hour RTO can rely on cold recovery from backups.
DR Architecture Patterns
Backup and Restore (RTO: 24h+, RPO: Hours)
The simplest and cheapest approach: - Regular automated backups to a different region or cloud provider - Infrastructure defined in code (Terraform/Pulumi) for rapid recreation - Tested restoration procedures documented as runbooks - Suitable for non-critical workloads and development environments
Cost: Backup storage only -- typically 5-10% of production infrastructure cost.
Pilot Light (RTO: 1-4h, RPO: Minutes)
Minimal core infrastructure running in the DR region: - Database replicas running continuously (asynchronous replication) - Core networking and security infrastructure pre-provisioned - Application servers defined in IaC but not running - Scale up by launching application servers from pre-built AMIs or containers
Cost: 15-25% of production infrastructure cost (primarily database replicas and networking).
Warm Standby (RTO: 15-60 min, RPO: Seconds-Minutes)
Scaled-down but functional copy of production: - All services running at minimum capacity in the DR region - Database replicas with near-synchronous replication - Load balancers and DNS pre-configured for failover - Scale up to full capacity when failover is triggered
Cost: 30-50% of production infrastructure cost.
Multi-Region Active-Active (RTO: < 5 min, RPO: Zero)
Full production capacity in multiple regions simultaneously: - Traffic distributed across regions using global load balancing - Databases with multi-region synchronous writes (DynamoDB Global Tables, CockroachDB, Spanner) - Automatic failover with no manual intervention - Highest availability but also highest complexity and cost
Cost: 100%+ of single-region production cost (you are running full capacity in two or more regions).
India-Specific DR Considerations
Data Residency During Failover
If your primary region is in India and your DR region is overseas, you need to address data residency: - Financial services data (RBI regulated) must stay in India -- use Mumbai and Hyderabad as primary/DR pair - Personal data under DPDPA may have cross-border transfer restrictions - Consider multi-cloud DR within India: AWS Mumbai primary with Azure Pune as DR
Cross-Cloud DR
Using a different cloud provider for DR protects against provider-level outages: - AWS Mumbai (primary) + Azure Central India (DR) - Requires cloud-agnostic tooling (Terraform, Kubernetes, standard databases) - Higher operational complexity but eliminates single-provider dependency
Regulatory Requirements
Several Indian regulators have explicit DR requirements: - RBI mandates DR drills for payment systems and core banking - SEBI requires documented Business Continuity Plans for market intermediaries - IRDAI expects DR capabilities for insurance companies - CERT-In incident reporting requirements apply during DR events
Testing Your DR Plan
A DR plan that has never been tested is not a plan -- it is a hope.
Types of DR Tests
Tabletop exercise: Walk through the failover procedure verbally with all stakeholders. Identify gaps in documentation and communication. Run quarterly.
Component test: Verify individual components (database restore, DNS failover, backup integrity). Run monthly.
Full failover test: Execute the complete failover to the DR region with real traffic. Run twice per year minimum.
Chaos engineering: Randomly inject failures in production to verify resilience. Start with non-critical services.
Test Checklist
For each DR test, verify: 1. Failover completes within the target RTO 2. Data loss is within the target RPO 3. All critical applications function correctly in the DR region 4. Monitoring and alerting work in the DR environment 5. Failback to the primary region works correctly 6. Communication procedures (team notifications, customer updates) execute properly
Getting Started
- Week 1: Classify all workloads by criticality and define RTO/RPO targets
- Week 2: Choose DR architecture pattern per workload based on targets and budget
- Month 1: Implement backup and restore for all workloads (baseline DR)
- Month 2: Implement pilot light or warm standby for critical workloads
- Month 3: Conduct first full DR test, document findings, iterate
At Optivulnix, we help Indian enterprises design and test cloud disaster recovery architectures that meet regulatory requirements without breaking the budget. Contact us for a free DR readiness assessment.
