There is a widely held but dangerously incorrect assumption in enterprise IT: that having backups means you have a disaster recovery capability. A backup is a copy of data at a point in time. Recovery is the validated, tested ability to restore operations to an acceptable state within an acceptable timeframe after a failure event. Many organisations have the first without having meaningfully invested in the second.

The distinction becomes clear during incidents. When the AIIMS Delhi ransomware attack in 2022 encrypted the hospital's servers, the institution discovered that its backup tapes existed but that restoring from them would take weeks — an unacceptable timeline for a facility managing critical patient care. Operations reverted to pen and paper for over a month. This is not primarily a backup technology failure. It is a recovery planning failure.

AWS, Azure, and Google Cloud all offer managed disaster recovery services — Elastic Disaster Recovery, Azure Site Recovery, and equivalent — that can replicate on-premises or cloud workloads continuously and restore them to a running state in minutes, not weeks. The cost of maintaining a standby recovery environment in cloud — paying only for storage, not compute, until a failover is triggered — is a fraction of maintaining an equivalent physical secondary data centre.

SEBI's Business Continuity Planning guidelines for market infrastructure institutions specify Recovery Time Objectives of 2 hours and Recovery Point Objectives of 30 minutes. RBI guidelines for banks set similar targets. Meeting these targets with tape-based backup and manual recovery procedures is not feasible.