Almost every enterprise has backups. Far fewer have a recovery they have actually tested, and the gap between the two does not announce itself until the worst possible moment. A backup is a copy you made. A recovery is proof that the copy restores — cleanly, completely, and fast enough to matter. The first is a line item in a procurement sheet; the second is the only thing that counts when ransomware, a failed migration or a corrupted database takes production down. At L&T Vyoma, we treat backup-as-a-service as a recovery discipline, not a storage one, because the hard truth is that most organisations discover the difference during the incident, not before it.
Backup Success Is Not Recovery Confidence
The gap shows up most clearly in the numbers. In Veeam's Data Trust and Resilience Report 2026, a survey of more than 900 senior IT and security leaders, 90% said they were confident they could recover within their defined recovery-time objectives. Yet only 28% of those actually hit by ransomware fully recovered all their affected data; on average, organisations got back 72%, and 44% recovered less than three-quarters. Veeam's own summary of the finding is blunt: confidence in recovery and proof of recovery are fundamentally different capabilities. Fenix24's 2026 State of Recoverability Report, drawn from more than 800 recovery engagements, shows where that confidence breaks. Only 0.5% of clients came close to their 24-to-48-hour recovery targets, and in 38% of engagements the business could not restore at all because the backup data was outdated, corrupt or improperly formatted. The backups existed; they simply were not recoverable. This is the single most expensive assumption in enterprise IT, and it is why the industry is moving the metric that matters from backup success to proven recoverability.
Why “It's Backed Up” Is Not “We Can Recover”
A backup that has never been restored is a hypothesis, not a safeguard. Three things separate a stored copy from a provable recovery. The first is a tested restore path: an actual rehearsal that brings a representative workload back within a defined recovery-time and recovery-point objective, run on a schedule rather than assumed. The second is immutability and isolation: a copy that ransomware cannot encrypt or delete, held in air-gapped or write-once storage, because attackers now go after the backup first. Veeam's research puts it at 93% of ransomware attacks targeting the backup repository, precisely to remove the escape route. The third is recovery sequencing: knowing the order in which identity, databases, applications and dependencies must come back, because restoring data without a documented runbook simply moves the outage from the storage layer to the integration layer. Backup-as-a-service earns its name only when it owns all three; otherwise it is cloud storage with a reassuring label.
The Modern Baseline: 3-2-1-1-0
The backup rule most enterprises grew up with — three copies, on two kinds of media, with one offsite — was written for a world of hardware failure, not ransomware. The baseline has moved. The current standard for cyber resilience adds two digits: 3-2-1-1-0. The extra 1 is an immutable or air-gapped copy that cannot be altered or deleted, so an attacker who reaches your backups cannot encrypt them too. The 0 is zero recovery errors, proven by regular automated testing rather than assumed. Around that baseline sits a set of capabilities the old model never had: cleanroom recovery, which validates and restores into an isolated, malware-free environment so you are not re-infecting production from a compromised backup; AI-driven anomaly detection, which flags a corrupted or tampered backup before you need it rather than at the moment of restore; and coverage that reaches beyond servers and VMs to cloud-native workloads, containers and SaaS platforms, where a growing share of enterprise data now lives and where “the provider backs it up” is usually not true. This is what modern backup-as-a-service is moving toward, and it is the right bar to buy against.
|
Rule |
What it means |
|
3 copies |
Production data plus two separate backup copies |
|
2 media |
Backups on at least two different storage types |
|
1 offsite |
At least one copy in a separate location or cloud region |
|
1 immutable |
At least one air-gapped or locked copy ransomware cannot alter |
|
0 errors |
Recovery verified by regular, automated testing |
The India Dimension: Where Does the Recovery Copy Live?
For an Indian enterprise, recoverability is now also a question of jurisdiction. Rubrik Zero Labs reported in 2025 that 80% of ransomware-hit Indian organisations ended up paying to recover their data — a direct consequence of recovery plans that could not deliver on their own. Under the DPDP Act, where your backup copy physically resides, and whether you can restore it lawfully and in time, is not an operational detail; it is a compliance position. A recovery copy sitting in a foreign region may be fast on paper and unusable in practice if a cross-border restriction lands mid-incident. The recovery you can rely on is the one whose data, and whose restore path, stay on Indian soil under your governance. That is the version we build for.
What Good Backup-as-a-Service Actually Looks Like
Our view is that backup-as-a-service should be sold on the recovery it can prove, not the capacity it can store. It sits inside our wider managed cloud services in India — secure cloud hosting, data center colocation services and disaster recovery data center solutions, all run on L&T-operated data centers. The managed backup and recovery service itself is built to the 3-2-1-1-0 baseline: immutable, air-gapped, in-country copies; recovery-time and recovery-point objectives set per workload rather than one blanket policy; cleanroom validation so a restore is proven clean before it touches production; anomaly detection on the backups themselves; and coverage that reaches cloud-native, container and SaaS workloads, beyond traditional infrastructure alone. Our managed services team owns the recovery runbook and the sequencing, rehearses restores on a schedule, and keeps the entire footprint DPDP-aligned and on Indian soil, so the copy and the restore are both lawful and local. We would rather be measured on a recovery test you watched succeed than on a backup report you never had to open.
|
Dimension |
Backup You Store |
Recovery You Can Prove |
|
Success metric |
Backup job completed |
Workload restored within RTO/RPO |
|
Against ransomware |
Repository can be encrypted |
Immutable, air-gapped copy |
|
Restore path |
Assumed, never run |
Rehearsed on a schedule; validated in a cleanroom |
|
Recovery order |
Figured out live |
Documented runbook and sequencing |
|
Workload coverage |
Servers and VMs only |
Also cloud-native, containers and SaaS |
|
Data location |
Wherever the service defaults |
Indian soil, DPDP-aligned |
Test the Recovery Before the Incident Does
The only backup that counts is the one you have restored. The cheapest time to find out whether your recovery works is on a quiet Tuesday in a rehearsal; the most expensive time is at 3 a.m. with production down and a ransom note on the screen. Backup-as-a-service, done properly, moves that discovery forward — to a scheduled test, on in-country infrastructure, against a target you have agreed. Talk to our team about a recovery test on your most critical workload, or explore our managed backup and disaster recovery services.