India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Pilot Light DR: Replicated Data, Dormant Compute, Hour-Level Recovery
Pilot light DR is a recovery pattern in which data is replicated continuously to a second region while application compute stays switched off, ready to be launched from templates when disaster is declared. NTSPL builds pilot light environments on AWS, Azure and Google Cloud for Tier 1 and Tier 2 services needing recovery in 30 minutes to four hours.
Delivered on
In scope
What Stays Lit and What Stays Dark in a Pilot Light Design
Many Indian mid-market systems need better than next-day recovery but cannot justify paying for a second set of running servers. Dealer portals, distributor ordering, internal ERPs and line-of-business applications typically lose INR 1-10 lakh per hour of outage: enough to make a 24-hour backup restore unacceptable, not enough to fund warm standby. The failure mode we see most is a 'DR' that is really just backups in another region, with no tested way to turn them into a running application, so real recovery takes a day of manual rebuilding.
NTSPL builds pilot light around one principle: everything that holds state replicates continuously, and everything else is code. Databases run as small cross-region replicas or block-level replication targets; application servers exist only as images and launch templates; networking, load balancers and DNS records are pre-created or one pipeline run away. Failover is a scripted sequence that promotes data, scales compute from zero and switches traffic, and we time it in drills.
Workloads That Suit Pilot Light Recovery
Signals you need Pilot Light DR
- The DR assessment placed the service in a tier with RTO between 30 minutes and 4 hours and RPO of 15 minutes or less.
- Outage cost is roughly INR 1-10 lakh per hour, so a running standby would cost more per year than the outages it prevents.
- Today's recovery is restore-from-backup into another region, with a rebuild time of 8-24 hours that has never been fully tested.
- The application already deploys from images or containers and infrastructure is mostly in code, or can be made so within weeks.
- You are exiting a secondary data centre and want DR compute billed only during drills and real events.
When to choose something else
- The service must be back within 15 minutes or cannot tolerate a cold application start. Use Warm Standby DR, or Active Active Resilience for near-zero RTO.
- The application needs manual installation steps, hardware dongles or licence keys bound to MAC addresses. Fix those first or use block-level replication of whole servers instead.
- Backup-restore already meets the agreed 24-hour RTO. Pilot light adds replication cost for no business gain; stay with Cloud Backup Architecture.
What NTSPL Builds in a Pilot Light Environment
Data replication
Cross-region database replicas, block-level server replication or storage replication for every stateful component, with lag alarms against the RPO.
Image and template pipeline
Golden images or container images rebuilt and copied to the DR region on every release, plus launch templates and scaling groups set to zero.
Pre-staged network and security
DR VPC, VNet or VPC network, subnets, security rules, private connectivity and key vaults created in advance, since these are slow to build under pressure.
Traffic switch
DNS failover records or global load balancer backends with low TTLs and health checks, ready to switch once the DR stack passes smoke tests.
Failover automation
A single orchestrated runbook that promotes replicas, scales compute, runs smoke tests and switches traffic, with manual approval gates.
Failback plan
Reverse replication and a scheduled failback window, so the business is not stuck in DR for weeks after the primary returns.
How Pilot Light DR Works, Step by Step
Pilot Light Topology: Replicated State, Templated Compute
In normal operation only the data tier runs in the DR region, receiving continuous replication from production. On declaration, an orchestrated runbook promotes the replica, launches compute from current templates, verifies the stack and moves traffic.
Select any component
Pilot Light Topology: Replicated State, Templated Compute: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Pilot Light Building Blocks per Hyperscaler
For server-based apps NTSPL uses Elastic Disaster Recovery, which keeps low-cost staging resources and launches recovery instances on demand; for modern stacks, Aurora replicas in Hyderabad plus Auto Scaling groups at zero.
Site Recovery replicates VM disks to South India without running target VMs, which is pilot light by design; recovery plans add ordered groups and scripts for start-up sequence.
Cloud SQL replicas in Delhi carry state; managed instance groups sized to zero reference images stored in a multi-regional location, and Terraform holds the rest.
Choices That Decide Pilot Light Recovery Time
Block-level server replication or native data replication
Use block-level replication (Elastic Disaster Recovery, Site Recovery) for lift-and-shift servers, Windows apps with local state or more than 10 servers with complex install steps; it gives RPO in seconds without app changes. Use native database replicas plus templated compute for modern apps already built from images; it recovers faster and costs less, but every stateful component must be identified.
Sizing the always-on replica
Size the DR replica to keep replication lag under one-third of RPO at peak write load, typically one or two sizes below production. Budget 10-15 minutes in the runbook to scale it up after promotion. Do not under-size so far that the replica falls behind during month-end or festive peaks; check lag history across the busiest week before choosing.
What to pre-create
Pre-create anything slow, rarely changing or needing approval: networks, private connectivity, firewall rules, key vaults, certificates, load balancers and IAM roles. Keep dormant anything billed by the hour: VMs, app containers, caches. As a rule, if a resource takes more than five minutes to create or depends on a third party, it should already exist.
Setting a realistic RTO
Add up measured durations: replica promotion (1-5 minutes), compute scale-out (5-15 minutes), cache warm-up and app start (5-20 minutes), smoke tests (10 minutes), DNS propagation (2-5 minutes) and decision time (often 15-30 minutes). Most pilot light designs land at 45-90 minutes; commit to an RTO only after the first timed drill.
From Replication to First Timed Failover
State inventory and replication design
Every stateful component is identified and assigned a replication method and RPO alarm, including file shares and queues often missed.
DR region foundation
Network, connectivity, keys, IAM and load balancers are built in code in the DR region and peered or connected as required.
Replication and image pipeline
Replication is started and seeded, and the release pipeline is extended to publish images and templates to the DR region.
Failover orchestration
The runbook is automated with approval gates and smoke tests, and the failback procedure is scripted.
First timed failover drill
A full failover to the DR region is run against a copy or in a maintenance window, timed per step, and the RTO is set from the measured result.
What you receive
Pilot Light Recovery and Cost Measures
| KPI | Typical target |
|---|---|
| Measured failover time in drill | 30 minutes to 4 hours, as agreed per tier |
| Replication lag at peak | Under one-third of RPO |
| DR region monthly run cost | Typically 10-20% of production compute and database cost |
| Releases with images published to DR region | 100% |
| Failback completed after drill | Within the agreed maintenance window |
Why Pilot Light Recoveries Overrun and How to Prevent It
| Risk | How NTSPL prevents it |
|---|---|
| Launched compute runs an old image | The release pipeline fails if the DR region copy of the image does not succeed, and the drill checks the running version against production. |
| DR region quota or capacity blocks scale-out | Service quotas are raised in advance and checked quarterly; for large fleets, on-demand capacity reservations are considered for the first wave of instances. |
| A forgotten stateful component | State inventory includes file shares, object buckets, queues, caches holding sessions and scheduled job state; the drill fails if any are missing. |
| Nobody can declare a disaster at 3 a.m. | Declaration authority and deputies are named in the runbook, with a decision timebox of 20 minutes after which the on-call lead may proceed. |
Pilot light vs warm standby: which DR pattern should we choose?
Choose pilot light when you can accept 30 minutes to a few hours of recovery and want DR to cost roughly 10-20% of production. Choose warm standby when recovery must be within about 15 minutes, when application start-up and cache warm-up are slow, or when you need confidence that the DR stack works every day rather than only during drills. Warm standby typically costs 25-50% of production because a scaled-down copy runs continuously. A useful test: if your measured pilot light drill exceeds RTO mainly because of compute start-up rather than data promotion, move to warm standby.
Key facts: Pilot Light DR
Pilot Light DR in Practice
2 Pilot Light DR scenarios, from Decorative paints (dealer ordering portal) and Automobile dealerships (dealer management system), plus related platform case studies.
Paints maker's dealer ordering portal recovers in 52 minutes from Hyderabad
Auto dealer group's DMS gets 2-hour recovery with Site Recovery to South India
Multi-specialty hospital cuts HIS recovery time from 2 days to 38 minutes
3PL operator cuts warehouse system recovery time from 2 days to 45 minutes
Pilot Light DR: Frequently Asked Questions
How much does a pilot light DR build cost?
For a typical three-tier application of 6-20 servers, a pilot light build takes six to eight weeks. Ongoing DR run cost is mostly the database replica, replication service and storage, usually 10-20% of the production bill. NTSPL provides a fixed build quote and an INR monthly run estimate before work starts.
Can pilot light work between two Indian regions?
Yes. Common pairs are AWS Mumbai to Hyderabad, Azure Central India to South India, and Google Cloud Mumbai to Delhi. Keeping both sites in India satisfies RBI payment data storage rules and CERT-In log retention without cross-border transfer questions. The DR region still needs its own quotas, keys and images prepared in advance.
Is AWS Elastic Disaster Recovery the same as pilot light?
It implements a form of pilot light for servers: data replicates continuously to low-cost staging resources, and full recovery instances are launched only during drills or failover. It is ideal for lift-and-shift servers; for cloud-native apps, native database replicas plus templated compute are often simpler.
Can we use pilot light for an on-premises application?
Yes. On-premises VMware, Hyper-V or physical servers can replicate into AWS, Azure or Google Cloud and launch there on failover. Network connectivity for users and integrations must be planned in advance, typically through VPN or SD-WAN to the DR region.
How do we fail back after a disaster?
Replication is reversed from the DR region to the restored primary, a sync period follows, and a planned failback runs during a low-traffic window. NTSPL scripts failback during the build, because teams that have not tested it often stay in DR far longer than planned.
Do drills disrupt production?
Not if run as isolated drills. Most tools can launch recovery instances into an isolated network while production replication continues. NTSPL recommends one isolated drill per quarter and a full traffic switch at least once a year. Each drill ends by tearing down launched instances so DR run cost stays low.