A disaster recovery plan (DRP) is the documented strategy an organisation follows to restore IT systems and data after a disruption — whether caused by ransomware, hardware failure, power failure, natural disaster or human error. In India, where CERT-In now mandates incident reporting within 6 hours and RBI requires BCDR planning for regulated entities, a documented DR plan is no longer optional.
This guide covers how Indian organisations should design, document and test a disaster recovery plan in 2026.
Disaster Recovery vs Business Continuity — The Difference
These terms are often used interchangeably but have distinct meanings:
Business Continuity (BC): The ability to keep critical business functions running during and after a disaster — even at reduced capacity. Business continuity planning covers people, processes and technology.
Disaster Recovery (DR): The specific IT process of restoring technology systems, data and infrastructure after a disruption. DR is a subset of business continuity focused on IT systems.
This guide focuses on IT disaster recovery — the systems, backups and procedures for restoring technology after an incident.
Two Critical Metrics: RTO and RPO
Every disaster recovery decision is driven by two numbers:
Recovery Time Objective (RTO)
How long can your business operate without this system?
RTO is the maximum acceptable downtime. If your ERP system has an RTO of 4 hours, you must be able to restore it to operation within 4 hours of a failure.
Examples:
- ERP/accounting system (Tally, SAP, Zoho Books): RTO typically 2–4 hours — the business cannot process orders, invoices or payroll without it
- Email (Microsoft 365, Google Workspace): RTO 1–4 hours — urgent communication delayed, but SaaS platforms have high inherent availability
- Active Directory / Domain Controller: RTO 1 hour — all other systems stop working without AD
- Development servers: RTO 24–48 hours — development can pause temporarily
Recovery Point Objective (RPO)
How much data can you afford to lose?
RPO is the maximum acceptable data loss, expressed as time. If backups run daily, your RPO is up to 24 hours — you may lose up to a day of data.
Examples:
- Database (SQL Server, Oracle): RPO 15 minutes — transaction log backup every 15 minutes
- File server: RPO 4 hours — hourly shadow copies or 4-hourly backup
- Email: RPO 24 hours — daily backup (with Microsoft 365, Microsoft retains deleted items for 30 days in the service itself)
- Archives / older files: RPO 7 days — weekly backup acceptable
The lower the RTO/RPO, the more infrastructure and budget required. The goal is to define what is acceptable per system, not to achieve zero RTO/RPO for everything.
Indian Regulatory Requirements for DR Planning
CERT-In (Computer Emergency Response Team — India)
CERT-In's April 2022 directions require all Indian organisations to:
- Report cybersecurity incidents (including ransomware) within 6 hours of discovery
- Maintain logs for 180 days on Indian territory
- Maintain ICT infrastructure inventory
Having documented DR procedures and immutable backups supports both compliance and incident response.
RBI Guidelines (Banking and NBFC)
RBI's IT framework (2011, updated) and Master Directions on IT require:
- Documented Business Continuity and Disaster Recovery (BCDR) plans
- Regular DR drills (minimum annually for category A banks)
- Recovery time commitments for critical systems
- Data backup at a geographically separated DR site
SEBI (Securities Brokers and Market Infrastructure)
SEBI requires securities brokers and market infrastructure institutions to maintain:
- Technology governance frameworks with DR provisions
- Critical systems restored within defined timeframes
- Off-site backup storage
IRDAI (Insurance)
IRDAI's information and cyber security guidelines require:
- Business continuity management framework
- DR site with documented recovery procedures
- Annual testing of DR procedures
NABH (Healthcare)
NABH accreditation standards for hospitals include:
- Patient data backup and recovery provisions
- IT service continuity planning
Disaster Recovery Tiers — What Level Does Your Business Need?
DR infrastructure is classified into tiers based on RTO/RPO capability:
| Tier | Description | RTO | RPO | Cost |
|---|---|---|---|---|
| Tier 0 | No DR — data loss is accepted | Days–weeks | Days | None |
| Tier 1 | Tape/physical backup only | Days | 24–48 hours | Low |
| Tier 2 | Local backup + manual recovery | Hours–days | 24 hours | Low-medium |
| Tier 3 | Local backup + instant VM recovery | Minutes–hours | 4–24 hours | Medium |
| Tier 4 | Backup + offsite copy | Minutes–hours | 4–24 hours | Medium |
| Tier 5 | Backup + warm DR site | Minutes | 1–4 hours | High |
| Tier 6 | Hot standby DR site | Seconds–minutes | Minutes | Very high |
| Tier 7 | Zero data loss (synchronous replication) | Seconds | Near-zero | Very high |
Most Indian SMB and mid-market organisations should target Tier 3–4 — local NAS-based backup with instant VM recovery capability and an offsite cloud copy.
DR Architecture for Indian Organisations — Practical Implementation
The Recommended Stack
For most Indian organisations (5–200 VMs), this architecture delivers Tier 3–4 DR at a cost that makes business sense:
Production Environment:
VMware ESXi / Hyper-V hosts → VMs running ERP, email, databases, file servers
Backup Layer (Tier 3):
NAKIVO Backup & Replication (running on QNAP NAS)
↓
QNAP NAS WORM volume (immutable — ransomware resistant)
↓ Instant VM Recovery: boot critical VMs from NAS backup in < 2 minutes
Offsite Layer (Tier 4):
NAKIVO backup copy job
↓
Wasabi S3 / AWS S3 with Object Lock (Indian Mumbai region)
— Recovery from cloud if primary site is destroyed
Components and Their DR Role
NAKIVO Backup & Replication:
- Runs on QNAP NAS — no separate Windows backup server
- Backs up all VMs (VMware/Hyper-V) with Changed Block Tracking — only changed data transferred
- Application-consistent backup for SQL, Exchange, Oracle
- Instant VM Recovery — boots VMs directly from backup repository (RTO < 2 minutes)
- Microsoft 365 backup — protects Exchange Online, OneDrive, SharePoint, Teams
QNAP NAS with WORM Volume:
- Physical backup repository storing all backup files
- WORM (Write Once Read Many) immutable volumes — ransomware cannot delete backup files even with admin credentials
- Snapshot protection — QNAP snapshots protect against accidental file deletion within the NAS
- 10GbE connectivity — fast backup write speed and fast VM restore speed
Cloud Backup Copy (Wasabi/AWS):
- Automated daily backup copy from QNAP NAS to cloud
- Wasabi Mumbai region provides Indian data residency + low cost (~$7/TB/month)
- S3 Object Lock provides cloud-side immutability
- Used when the primary site is physically compromised (fire, flood, theft)
Disaster Recovery Plan — Document Template
A DR plan document should contain these sections:
Section 1 — Scope and Objectives
Organisation: [Company Name]
Plan Owner: [IT Manager / CTO]
Last Updated: [Date]
Last Tested: [Date]
Next Review Date: [Date + 6 months]
Scope: This plan covers recovery of IT systems at [Primary Site Address]
following a disruption classified as a disaster under this plan's criteria.
Objectives:
- Restore critical IT systems within defined RTO targets
- Limit data loss to within defined RPO targets
- Communicate status to key stakeholders within 1 hour of declaration
Section 2 — System Inventory and Priority
| System | Business Function | RTO | RPO | Recovery Priority |
|---|---|---|---|---|
| Active Directory | All system authentication | 1 hour | 4 hours | P1 — Critical |
| ERP (SAP/Tally/Zoho) | Business operations | 4 hours | 1 hour | P1 — Critical |
| Email server/M365 | Communication | 2 hours | 24 hours | P1 — Critical |
| Database server (SQL) | Application data | 2 hours | 15 minutes | P1 — Critical |
| File server | Documents | 8 hours | 4 hours | P2 — High |
| Development servers | Development work | 48 hours | 24 hours | P3 — Standard |
Section 3 — Disaster Declaration Criteria
When to declare a disaster (triggering this plan):
- Production systems unavailable for more than [X] hours
- Ransomware attack confirmed on production environment
- Physical destruction of primary data centre (fire, flood, power failure beyond UPS capacity)
- Complete network connectivity loss for more than [X] hours
Section 4 — Recovery Procedures
Step 1 — Immediate response (first 30 minutes):
- Isolate affected systems from the network (prevent spread of ransomware/malware)
- Notify DR plan owner and management
- Assess scope — which systems are affected, what is the cause
- Check NAKIVO dashboard — confirm last successful backup dates for each system
- Declare disaster if criteria met (Section 3)
Step 2 — Recovery initiation:
- Open NAKIVO Backup & Replication dashboard on QNAP NAS
- Identify the most recent clean recovery point (pre-incident)
- Start Instant VM Recovery for P1 systems:
- NAKIVO → Recover → Instant VM Recovery
- Select VM, select recovery point, select target ESXi host
- VMs are operational in under 2 minutes
- Notify stakeholders that P1 systems are being recovered
Step 3 — Full environment recovery:
- After P1 systems are running from instant recovery on NAS, migrate to production storage
- NAKIVO migrates VM data back to production storage while VM runs (no extended downtime)
- Recover P2 systems via full restore to rebuilt or replacement hardware
- Verify each system: login, application test, data integrity check
Step 4 — Cloud recovery (if primary site destroyed):
- Provision temporary infrastructure (cloud VMs or alternative site)
- In NAKIVO — add cloud repository (Wasabi/AWS) as recovery source
- Recover VMs from cloud backup copy
- Estimated RTO from cloud: 4–12 hours depending on data volume and bandwidth
Step 5 — Post-recovery:
- Audit cause of the incident — prevent recurrence
- Reset compromised passwords, patch vulnerabilities
- Verify no malware remains before reconnecting to production network
- Document incident timeline and recovery steps for compliance reporting (CERT-In 6-hour reporting)
Section 5 — Contact List
DR Plan Owner: [Name] — [Phone] — [Email]
IT Manager: [Name] — [Phone] — [Email]
Managing Director: [Name] — [Phone] — [Email]
Internet/Network ISP: [Provider] — [Support number]
Backup Vendor: Cloudfy Systems — +91 97600 50555
NAKIVO Support: [Support contact from Cloudfy]
Cloud Provider: [AWS/Wasabi support number]
DR Testing — How to Test Without Disrupting Production
A DR plan that has never been tested is not a DR plan — it is a hope. Test these scenarios annually at minimum:
Test 1 — Instant VM Recovery (quarterly)
- In NAKIVO, select a non-critical VM
- Start Instant VM Recovery to an isolated network segment
- Verify VM boots successfully
- Confirm applications are accessible
- Power off and delete the test recovery
This does NOT affect production. The original VM continues running. The test recovery is on a separate network.
Test 2 — File-Level Recovery (quarterly)
- In NAKIVO → Recover → Files
- Browse backup of a file server
- Recover 10 random files to a test location
- Verify file integrity and accessibility
Test 3 — Full DR Drill (annually)
During a scheduled maintenance window:
- Shut down P1 systems on production
- Execute the full recovery procedure from Section 4
- Measure actual RTO vs. target RTO
- Document gaps and update the plan
Frequently Asked Questions
Is disaster recovery mandatory for Indian businesses? Mandatory for regulated sectors (banking under RBI, insurance under IRDAI, securities under SEBI). Strongly recommended for all businesses — CERT-In's 2022 directions require all organisations to maintain ICT infrastructure inventory and report cyber incidents within 6 hours.
What is the difference between backup and disaster recovery? Backup is the copy of your data. Disaster recovery is the complete process of restoring IT systems to operation — using backup data, restoration procedures, replacement infrastructure and documentation. Backup is a component of DR; DR is the overall plan.
How often should DR plans be tested in India? Regulated entities: annually at minimum, as mandated by RBI/IRDAI/SEBI. Other organisations: annually for a full DR drill, quarterly for component tests (VM recovery test, file recovery test). The plan should be reviewed and updated every 6 months or after any significant infrastructure change.
What is an acceptable RTO for Indian SMBs? For most Indian SMBs, 2–4 hours RTO for critical systems is achievable with NAKIVO instant VM recovery on QNAP NAS. Zero-downtime (Tier 6/7) requires significantly higher investment and is typically only justified for financial services and healthcare.
How much does a disaster recovery solution cost in India? For a 30-VM environment: QNAP 8-bay NAS (₹2,50,000–3,50,000) + NAKIVO licence (contact for pricing) + Wasabi cloud (~₹6,000/month). This achieves Tier 3–4 DR. Compare this to the cost of an unrecovered ransomware attack: the average ransom demand for Indian SMBs has been reported in the range of $50,000–$200,000 (₹40L–₹1.6Cr) with no guarantee of data recovery.
For disaster recovery planning and implementation in India, contact Cloudfy Systems. We design and deploy NAKIVO Backup & Replication on QNAP NAS storage as a complete backup and DR stack — with RTO/RPO planning, WORM immutable storage, cloud copy configuration and DR testing, with GST invoicing across India.