IT Glossary · Business Continuity
Disaster recovery is the set of tools, procedures and tested plans a business uses to restore its IT systems and data after an outage — hardware failure, ransomware, flood, fire or power loss. It answers two questions: how much data can we afford to lose, and how long can we afford to be down.
Disaster recovery is often confused with backup, and the distinction is the single most useful thing to understand about it. A backup is a copy of your data. Disaster recovery is the ability to be operating again — applications running, staff working, customers served — within a defined time. You can hold perfect backups and still have no disaster recovery, which is exactly the position many businesses discover themselves in on the worst possible day: the data exists, but restoring a domain controller, rebuilding an ERP server and reconfiguring the network takes eleven days. Everything in DR is built around two numbers. Recovery Point Objective (RPO) is how much data you are willing to lose, measured in time — an RPO of four hours means you accept losing up to four hours of work, which in turn dictates how often replication or backup must run. Recovery Time Objective (RTO) is how long you are willing to be down before systems are usable again. Those two numbers drive every technical and commercial decision that follows, and they should be set by whoever owns the business consequence, not by IT. A plan without a tested restore is not a plan; the industry has a long, well-documented history of organisations discovering their backups were unreadable only when they needed them.
Two forces have made disaster recovery a board-level question for Indian businesses rather than an IT housekeeping item. The first is ransomware, which now targets Indian SMEs at scale precisely because they are less likely to hold immutable backups — and modern strains deliberately encrypt backup repositories first, which is why an offline or immutable copy is no longer optional. The second is regulatory: CERT-In directions require incident reporting within six hours and 180 days of log retention held in India, while RBI and IRDAI impose their own continuity and recovery expectations on regulated entities, and enterprise customers increasingly ask for RPO and RTO commitments in contracts before they will sign. There is also a plainly physical dimension that gets overlooked — power reliability varies widely across Indian industrial areas, and monsoon flooding has taken out ground-floor server rooms in Mumbai, Chennai and Kerala within recent memory. For most Indian SMEs the practical answer is not a second data centre but cloud backup with immutability, an RTO measured in a day or two, and a restore test on the calendar twice a year.
Related terms: Business Continuity, RPO, RTO, Cloud Backup, Immutable Backup, Ransomware, Failover, High Availability, 3-2-1 Rule, CERT-In
Disaster recovery is how an organisation restores IT systems and data after an outage — ransomware, hardware failure, fire, flood or extended power loss. It is defined by two numbers: Recovery Point Objective, how much data you can afford to lose, and Recovery Time Objective, how long you can afford to be down. Everything else — the technology, the site, the cost — follows from where you set those two.
A backup is a copy of your data. Disaster recovery is the ability to be operating again within a defined time. The difference becomes concrete during an incident: you may hold every file safely and still need eleven days to rebuild servers, reinstall applications, reconfigure networking and restore a domain controller. Backup is necessary and not sufficient. If nobody has written down and tested the restore sequence, you have backup, not disaster recovery.
RPO — Recovery Point Objective — is the maximum data loss you accept, in time. A nightly backup gives an RPO of up to 24 hours, meaning a failure just before the backup runs loses a day of work. RTO — Recovery Time Objective — is how long until systems are usable again. Both should be set by the business rather than by IT, because both are commercial judgements about tolerable loss, and both drive cost sharply: halving either roughly doubles the spend.
It scales with how aggressive your RPO and RTO are. Cloud backup with a 24-hour RPO and a one-to-three-day RTO starts around ₹2,400 per endpoint or ₹2,800 per user per year — affordable for almost any business. Warm standby, where infrastructure sits ready in an Indian cloud region for an RTO of a few hours, typically runs 30-60% of your production infrastructure cost. A hot site with near-zero RTO approaches doubling it. Most Indian SMEs are correctly served by the first option.
Twice a year at minimum, and after any significant infrastructure change. Test an actual restore to usable systems, not merely that the backup job reported success — those are entirely different claims. Expect the first test to fail on something mundane: an expired service credential, a missing licence key, an undocumented dependency between two servers. Finding those during a scheduled test is the entire point.
Only if it is immutable or genuinely offline. Modern ransomware deliberately hunts for backup repositories and encrypts or deletes them before triggering, and a cloud backup your servers can write to is reachable by anything running with those credentials. What defeats it is immutability — backups that cannot be modified or deleted for a defined retention window regardless of credentials. Confirm your provider offers it and that it is switched on; it frequently is not enabled by default.
Three copies of your data, on two different types of media, with one copy offsite. The modern extension is 3-2-1-1-0: one of those copies immutable or air-gapped, and zero errors on a verified restore test. It remains good guidance because it defends against different failure modes simultaneously — hardware failure, site loss and ransomware each defeat a different single-copy strategy.
For most Indian SMEs, cloud backup with immutability is enough, and a second physical site is an expensive answer to a question they do not have. The test is straightforward: work out what one, two and three days of downtime actually cost your business. If a two-day recovery is survivable, cloud backup at a few thousand rupees per user per year is the right answer. If it is not — payments, healthcare, manufacturing lines, contact centres — then warm standby infrastructure becomes justifiable on the numbers rather than on anxiety.
Who has authority to declare a disaster, the order in which systems must be recovered and what depends on what, where credentials and licence keys are held, vendor and carrier contact details with account numbers, and how to communicate with staff and customers while systems are down. Keep it printed or on a device independent of the affected systems — a runbook stored only on the file server you are trying to restore has failed at the moment it is needed.
Not sure whether your backups would actually restore? We run a no-obligation DR readiness check — WhatsApp +91 98119 98370.