Testing disaster recovery properly: a practical guide for Indian IT teams

Most IT teams I speak to can tell me when their last backup ran. Far fewer can tell me when they last restored from it, how long it took, or whether the application actually worked afterwards. That gap is where disaster-recovery plans fail — not in the backup job, but in the recovery nobody rehearsed.

This guide is for IT heads and infrastructure teams who run their own servers, a VMware estate or workloads in a colocation hall. It covers what to test, in what order, and what evidence to keep. It is practical guidance; where your regulator or auditor sets a stricter rule, theirs wins.

Why this matters more every year

Attackers now go after the backups first. In Sophos's State of Ransomware 2024 survey of 5,000 IT and security leaders in 14 countries, 94% of organisations hit by ransomware said the attackers tried to compromise their backups, and 57% of those attempts succeeded. The same survey put the average cost of recovery, excluding any ransom, at US$2.73 million — up from US$1.82 million a year earlier.

Regulators have noticed. According to KPMG's summary of the Reserve Bank of India's technology directions issued on 31 July 2026, disaster-recovery drills for critical information systems must be conducted at least half-yearly, and any major issue found in a drill must be fixed and re-tested before the next cycle. Even if you are not regulated by the RBI, that is a sensible bar to hold yourself to.

A backup you have never restored is a hope, not a plan.

Start with two numbers

Every DR test is measured against two targets, agreed with the business rather than set by IT alone. The recovery time objective (RTO) is how long a system can be down. The recovery point objective (RPO) is how much data, measured in time, you can afford to lose. A payments system may need minutes; an internal wiki may tolerate a day. Write both down for every important system. Without them, a test can only tell you that something worked — not whether it worked well enough.

Four levels of test, in order

Build up to it; do not attempt a full failover on day one. NIST's contingency-planning guide (SP 800-34) separates discussion-based tabletop exercises from functional exercises that actually operate the systems. The ladder below follows the same idea.

1. Tabletop. Put the people who would respond in one room with a scenario — say, ransomware encrypts the main file server at 2 a.m. on a Saturday — and walk the runbook step by step. Who gets called? Who decides to fail over? Where are the credentials if the identity system is down? A tabletop costs an afternoon and finds the gaps in roles, contacts and decisions before they hurt.

2. Restore test. Pick sample workloads — one database, one file share, one virtual machine — and restore them into an isolated network. Time it. Then check that the result actually works: the database opens and its records are current, the application starts, users can log in. A restore that completes but leaves an unusable system is a failed test.

3. Partial failover. Fail one complete service over to the DR site or cloud region, together with its dependencies — DNS, identity, certificates, firewall rules, integrations. Run it there for an agreed window, then fail back. Failback is often harder than failover, and it is the step teams most often skip.

4. Full DR drill. Fail over everything critical as you would in a real disaster, with business users confirming that they can work. It is expensive and disruptive, so it is scheduled, approved and attempted only after the lower levels pass.

The checklist

1. Inventory what is protected. List every system with its backup job, target, retention and last successful run. The systems missing from that list are the ones that are not protected.

2. Follow 3-2-1, and add immutability. Keep at least three copies of important data, on two different types of storage, with one copy off-site. Because attackers target backups, make at least one copy immutable or offline, so that a compromised administrator account cannot delete it.

3. Separate the backup credentials. The backup system should not trust your main domain. Use separate accounts, multi-factor authentication and, where you can, a separate management network.

4. Test on a schedule, not on request. A monthly restore of a rotating sample, a half-yearly drill for critical systems, and a test after every major change — new storage, a hypervisor upgrade, a migration.

5. Restore into isolation. Test restores land in a sandboxed network, so a restored system cannot collide with production or bring malware back with it.

6. Measure against RTO and RPO. Record how long the restore actually took and how old the restored data was. Compare both with the targets and log the gap.

7. Keep runbooks where a disaster cannot reach them. If the runbook lives only on the file server that has just been encrypted, you do not have a runbook. Keep a current copy outside the main environment, including on paper for the first hour.

8. Test the dependencies explicitly. Most failed recoveries fail on something small: an expired certificate, a licence server, a hard-coded IP address, DNS. Put each on the test plan by name.

9. Protect the logs as well. CERT-In's directions of 28 April 2022 require logs of ICT systems to be kept for a rolling 180 days within India. Make sure log stores are inside your backup and DR scope — after an incident, they are the evidence.

10. Write it up and fix what you found. Every test ends with a short report: what was tested, timings against targets, what failed, who owns each fix and when it will be re-tested. A test without follow-up has wasted its cost.

What good evidence looks like

Auditors and boards do not want to hear that DR was tested; they want to see it. For each test, keep the scope and date, the people involved, logs or screenshots of the restore, start and finish times, the RTO and RPO achieved, and the issues raised with their closure. Over a year, that record is what turns “we have DR” into something you can prove.

If you only do three things this quarter

First, agree RTO and RPO for your five most important systems with their business owners. Second, restore each of them into an isolated network and time it. Third, confirm that at least one backup copy is immutable or offline and cannot be deleted with your everyday administrator accounts.

Where Zyvark fits

This is the work behind our Backup & DR readiness assessment: an inventory of what is protected, a live restore test of sample workloads, a review of your runbooks and last drill, a check of log retention against CERT-In's 180 days, and a written report with a 90-day plan. The scope and fee are fixed and agreed before we start, and the report is yours whether or not you work with us afterwards. If you would rather run it yourself, use this checklist — it is the one we use.

Sources

Sophos, The State of Ransomware 2024 (April 2024) — survey of 5,000 IT and cybersecurity leaders in 14 countries; 94% reported attempted backup compromise, 57% of attempts successful; average recovery cost US$2.73 million excluding ransoms. KPMG India, “RBI's technology-focused Master Directions issued on 31 July 2026” (September 2026) — DR drills for critical information systems at least half-yearly. NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — tabletop and functional exercises. CERT-In, Directions under section 70B(6) of the IT Act, 2000 (28 April 2022) — 180-day log retention within India. This article is general guidance; for regulated entities, the regulator's own text prevails.