Enterprise Cloud Backup: RPO, RTO and the 3-2-1-0 Rule, Priced in INR
Most backup conversations in Indian enterprises still start with a storage question: how many terabytes, how many rupees per GB.
The more useful starting question is a timing one. If ransomware hits tonight, how much data can the business afford to lose, and how many hours can it afford to be down while restoring the rest? Enterprise cloud backup solutions built around those two numbers, not around storage volume alone, are the ones that hold up when an incident happens rather than during the calm demo that sold the contract.
The stakes are real enough to justify the caution. Among Indian organisations hit by ransomware in the past year, only about 12% managed to fully recover their encrypted or stolen data, according to an OpenText-commissioned industry survey reported by Varindia. Separately, ITIC’s 2024 Hourly Cost of Downtime Survey found that over 90% of midsize and large enterprises now report a single hour of downtime costing more than 300,000 dollars. Neither number is decorative. Both point at the same underlying question this article is built around: not whether a business has backups, but whether it has tested, priced, and correctly targeted ones.
RPO and RTO Are Not the Same Conversation
Recovery Point Objective is determined by how frequently a system captures or replicates recoverable state, whether that’s a scheduled backup, continuous replication, or application-level transaction logging. It answers the question of how much data loss is tolerable, measured in time. Recovery Time Objective depends on the speed and readiness of the recovery path itself, the infrastructure, the runbooks, and the people, once a decision to restore has been made. These sound similar but drive completely different engineering decisions.
Conflating the two is a common planning mistake among Indian mid-market companies buying enterprise data storage solutions for the first time. A business can have an excellent RPO, near-continuous replication, and still fail badly on RTO if restoring from that state takes eighteen hours because nobody tested the restore process end to end. If a provider claims a sub-interval RPO without explaining the replication or application-consistency mechanism producing it, that’s worth asking about directly before assuming the number is real under load.
The 3-2-1-0 Rule Extends 3-2-1, It Doesn’t Replace It
The original 3-2-1 backup rule asks for three copies of data, on two different media types, with one copy stored offsite. It remains a sound baseline, built primarily around hardware failure and physical disaster scenarios. The 3-2-1-0 framework extends that principle by adding a zero-error verification requirement, meaning backups are actively tested and confirmed to restore cleanly, not assumed to work because a job completed without throwing an error.
That verification step is the part most organisations skip, and it matters more now than when 3-2-1 was first popularized, because a growing share of incidents involve an attacker already inside the network specifically targeting backup infrastructure before triggering encryption elsewhere. Regular restore testing exposes bottlenecks before an actual incident and gives a team a measured, current baseline for real recovery time, rather than a number carried over from whenever backups were last configured.
Pricing an Enterprise Backup Strategy in India
Backup pricing in India is rarely a single number, and treating it as one is how budgets go wrong. A realistic model separates at least four components: primary block storage behind live production workloads, snapshot storage for point-in-time recovery, VM-level backup jobs run on a schedule, and object storage for longer-term archival or cold copies. Cloud block storage solutions in particular tend to get priced by performance tier rather than a flat rate, since each has a distinct cost profile depending on the underlying infrastructure it sits on.
As a working example, a 2 TB production environment can be priced by modelling each layer separately rather than accepting a bundled monthly quote: cloud based block storage sized to the workload, a defined number of retained snapshots for fast point-in-time rollback, scheduled VM backup jobs at a lower per-GB rate since they’re typically compressed and less latency-sensitive, and an object storage tier for anything moved to longer-term retention. The relative ordering matters more than any single figure here, snapshots generally cost more per GB than VM backups because they preserve more restoration fidelity, and object storage is typically the cheapest layer precisely because it’s built for infrequent access rather than fast recovery.
Building a Backup Strategy Around Actual RPO and RTO Targets
The practical sequencing that works is setting RPO and RTO targets by system criticality first, then buying storage and backup frequency to match, rather than buying a generic plan and hoping it fits. A payments database might need a fifteen-minute RPO and a two-hour RTO. An internal reporting system might tolerate a 24-hour RPO and a full day to restore. Sizing cloud block storage for business workloads this way, tier by tier rather than uniformly, wastes less money on the low-priority systems and, more importantly, avoids under-protecting the ones that actually matter.
Retention windows deserve the same tiered thinking rather than a single default. Ninety days is a common planning starting point for general operational recovery, but the right window for a given business depends on its sector, compliance obligations, typical ransomware dwell time before detection, and how long a legal hold might realistically need to extend. Testing the restore process on a fixed schedule, quarterly at minimum for the most critical systems, is what actually converts a backup plan into a working enterprise cloud backup solutions strategy rather than a checkbox exercise nobody has verified.
What This Looks Like on Neon Cloud
Neon Cloud doesn’t offer an out-of-the-box fifteen-minute RPO as a single toggle, and it’s worth saying that plainly rather than implying otherwise. What it does provide is a set of separately priced building blocks a team can assemble to hit a specific RPO and RTO target. VM-level backups run at roughly 2 rupees per GB, suited to scheduled, lower-frequency recovery points. Snapshots, which preserve a more immediate, application-consistent recovery point, are priced separately at roughly 5.75 rupees per GB, reflecting the higher fidelity and faster restore they enable. Object storage sits at roughly 2.50 rupees per GB for archival and longer-term retention, and block storage pricing varies by performance tier depending on the IOPS and latency a workload actually needs.
For an aggressive RPO, a fifteen-minute target on a payments database, the practical path on Neon Cloud runs through frequent snapshots or application-level replication rather than relying on VM backups alone, since VM backups are priced and built for a lower-frequency recovery pattern. For less critical systems, scheduled VM backups paired with object storage retention are usually the more cost-effective fit. Neon operates data centers in Delhi NCR and Mumbai, which gives Indian customers the option to design a geographically separated recovery architecture between the two, subject to how the specific backup service and replication are actually configured rather than as an automatic property of having two locations. It’s also worth being precise that operating Indian data centers supports data residency planning under the DPDPA, but it doesn’t by itself constitute full compliance, which depends on the business’s own data processing practices and obligations as a fiduciary.
The Bottom Line
RPO and RTO aren’t compliance paperwork. They’re the two numbers that determine whether a ransomware incident is a bad week or an existential one, and the 12% full-recovery figure among affected Indian organisations is exactly the outcome that shows up when those numbers were assumed rather than tested. The 3-2-1-0 framework exists specifically to close that gap between believing a recovery target is achievable and knowing it, because untested confidence is precisely where recovery plans fail under real pressure.
Enterprise cloud backup solutions priced transparently, by component, in INR, and built around targets that have actually been rehearsed are the difference between an organisation that recovers in hours and one that discovers its backup plan only worked in theory.
Frequently Asked Questions
1. What makes enterprise cloud backup solutions different from standard cloud storage?
Enterprise cloud backup solutions are built around defined RPO and RTO targets and regularly tested restore procedures, not just stored data. Standard cloud storage holds files. It doesn’t guarantee a specific recovery time or confirm that a restore will actually succeed when it’s needed.
2. How should Indian businesses split budget across enterprise data storage solutions for production versus backup?
Production workloads need fast block storage for low latency, while backup and archival data are better suited to cheaper object storage tiers. Mixing the two without separating by access pattern usually means overpaying for performance that backup data never actually needs.
3. Why does block storage pricing vary more than object storage pricing in India?
Cloud block storage solutions are priced by performance tier, since they’re built for low-latency, high-IOPS access behind live databases and applications, and faster tiers cost more to provision. Object storage is priced more uniformly because it’s optimized for infrequent access rather than speed.
4. How should a business decide its backup retention window?
Ninety days is a reasonable planning starting point for cloud block storage for business use cases, but the right window depends on sector, compliance obligations, typical attacker dwell time before detection, and any legal hold requirements. Regulated industries often need longer retention.
5. Does having data centers in two cities automatically satisfy the offsite requirement in 3-2-1-0?
Not automatically. Two locations create the option for a geographically separated recovery architecture using cloud based block storage and replication, but the offsite requirement is only met if that setup is specifically configured, not just because the data centers happen to exist.