Backup and Disaster Recovery on Azure, AWS and Google Cloud: What Indian Enterprises Get Wrong

Every cloud platform sells a backup service, and most Indian enterprises have one switched on. Far fewer can say what their recovery time actually is, when they last restored anything, or whether the copy a ransomware operator would go for first is one the operator can delete. Backup is the easiest control to buy and the hardest to prove, and the auditor's questions, a bank's in particular, are all about proof.

This article is organised around the five decisions that decide whether a backup and disaster recovery setup works: what is in scope, what recovery you are promising, which Indian regions the copies sit in, whether the copies can be destroyed, and how often you test. For each one the platform specifics for Azure, AWS and Google Cloud are side by side, followed by the cost traps that make backup one of the fastest-growing lines on many bills, and what a bank's auditor will ask to see. Service names and defaults were checked against the three providers' documentation in October 2026; they change, so confirm the current terms before you depend on them. The regulatory references are a guide, not legal advice; confirm how they apply to you with counsel.

• 3-2-1-1-0: three copies, two media, one off-site, one immutable, zero restore errors: a common benchmark auditors use
• 14 days: the default soft-delete window on Azure Backup, now always on and extendable to 180 days
• 3: recovery tiers: replication and failover where the business needs minutes, ordinary backup everywhere else

Decision 1: what is actually in scope

The first mistake is to equate "we back up the VMs" with "we are backed up". A modern estate holds data in at least six places, and the native backup tool on each platform covers them unevenly.

• Virtual machines and disks. Azure: Azure Backup, VM-level, application-consistent for Windows; AWS: AWS Backup with EBS snapshots; application consistency needs VSS on Windows; Google Cloud: Backup and DR service; disk snapshots; The gap to watch: Linux databases on VMs need a pre-snapshot quiesce script or a database-native backup
• Managed databases. Azure: Azure SQL and Managed Instance automated backups with point-in-time restore; long-term retention is a separate setting; AWS: RDS automated backups and snapshots; long-term copies through AWS Backup; Google Cloud: Cloud SQL automated backups and point-in-time recovery; The gap to watch: Automated backups are short-lived by default; the retention an auditor wants has to be configured
• Object and file storage. Azure: Blob soft delete and versioning; Azure Files share snapshots and backup; AWS: S3 versioning and replication; AWS Backup for EFS and FSx; Google Cloud: Cloud Storage versioning and turbo replication; Filestore backups; The gap to watch: Versioning is not a backup if the attacker can purge versions; see decision 4
• Kubernetes workloads. Azure: AKS backup through Azure Backup; AWS: EKS cluster and volume backup through AWS Backup; Google Cloud: GKE Backup for GKE; The gap to watch: Cluster state and persistent volumes are different things; most setups do one
• Microsoft 365 and other SaaS. Azure: Not covered by Azure Backup; Microsoft's retention policies are not a restorable backup; AWS: Same; Google Cloud: Same; The gap to watch: A separate purchase: Microsoft 365 Backup for Exchange, SharePoint and OneDrive, or a third-party product (needed for Teams)
• Configuration and infrastructure code. Azure: Azure Resource Manager exports, Bicep or Terraform in source control; AWS: CloudFormation or Terraform in source control; Google Cloud: Terraform or Infrastructure Manager in source control; The gap to watch: A region outage with no reproducible infrastructure definition turns a restore into a rebuild

Write the scope down before anything else. One page: every system, its data location, which tool protects it, and which line above it falls under. Common findings are a production database on a VM whose daily snapshot was never application-consistent, and a SaaS platform with no backup at all.

Decision 2: the recovery you are promising

Recovery point objective is how much data you can lose; recovery time objective is how long you can be down. Pick them per workload, in writing, with the business, and let them drive the tool, because the tool for a 15-minute RPO is not a backup at all.

• 1. Continuous. Typical workloads: Core banking, payments, ERP, the customer-facing transaction path; RPO: Minutes; RTO: 1–4 hours; What delivers it: Replication to a second region with orchestrated failover: Azure Site Recovery, AWS Elastic Disaster Recovery, or database-native replication such as Azure SQL failover groups and RDS Multi-AZ with cross-region read replicas
• 2. Frequent. Typical workloads: Internal applications, reporting, file services; RPO: 1–4 hours; RTO: 8–24 hours; What delivers it: Backups several times a day, restorable in the same region, with a copy in the paired region
• 3. Daily. Typical workloads: Development, test, archives, anything rebuildable; RPO: 24 hours; RTO: Days; What delivers it: Daily backup with standard retention

The common error is to treat everything as tier 2, which under-protects the transaction path and over-pays for the rest. The second error is to promise tier 1 on paper and deliver it with a nightly backup; the gap only shows on the day. Our data replication service exists for the first tier, where the answer is replication and failover rather than backup and restore.

Decision 3: which Indian regions hold the copies

Latency, sector rules and most customer contracts point the same way: keep the copies in India. The DPDP Act does not by itself require it: it lets the government restrict transfers to notified countries, and only Significant Data Fiduciaries can be required to keep specified data in India. RBI's payment data rules, by contrast, do require payment data to stay in India. The three platforms give you different ways to do that.

• Azure. Indian regions: Central India, India South Central (Hyderabad), South India, West India; Pairing for the second copy: Central India and South India are a designated pair; West India pairs with South India, and India South Central with Central India; What cross-region restore needs: Geo-redundant vault storage (the default for a new vault) with Cross Region Restore switched on, which is off by default and cannot be turned off again once protection starts
• AWS. Indian regions: ap-south-1 (Mumbai), ap-south-2 (Hyderabad); Pairing for the second copy: No fixed pairs; you choose, and Mumbai to Hyderabad keeps the copy in India; What cross-region restore needs: A cross-region copy rule in the backup plan, into a vault in the second region, ideally in a separate account
• Google Cloud. Indian regions: asia-south1 (Mumbai), asia-south2 (Delhi); Pairing for the second copy: No fixed pairs; a custom dual-region of the two keeps storage in India; What cross-region restore needs: Backup vault or bucket in the second region, with the restore path tested from there

The trap is the default. An Azure vault without Cross Region Restore, or one switched to locally redundant storage to save money, a single-region backup plan or a regional bucket all protect against a deleted file, and none of them protects against losing the region. Decide tier by tier which workloads need the second region at all; tier 3 usually does not, and that decision pays for the tier 1 replication.

Decision 4: can the copies be destroyed?

Ransomware operators learned years ago that the backup is the first target: delete it, then encrypt production, then negotiate. The control is immutability, which each platform now offers, combined with separation, so that the credentials that run production cannot touch the copies.

• Azure. Immutability: Immutable vault, locked so the setting cannot be reversed; soft delete, extended beyond the 14-day default; Separation: Multi-user authorisation through Resource Guard in a separate subscription or tenant, so one administrator cannot disable protection alone; Also switch on: Alerts on backup deletion and policy change
• AWS. Immutability: Backup Vault Lock in compliance mode, which even the account root cannot undo once the cooling-off period ends; Separation: Copies into a vault in a separate account under the organisation, with no production role allowed to assume into it; Also switch on: S3 Object Lock for critical buckets; MFA delete on versioned buckets
• Google Cloud. Immutability: Backup vault with enforced retention; bucket retention policy with retention lock; Separation: Backups in a separate project with its own IAM, no production service account granted access; Also switch on: Alerts on retention policy changes through Cloud Audit Logs

Immutable and separate, not one or the other. An immutable vault in the same subscription with the same owners can still be wiped by the owner's compromised account on platforms where the lock is reversible. A separate account without immutability can be emptied by anyone who gets into it. The auditor's question is "show me the configuration that would stop your own global administrator deleting last week's backup", and the answer has to be both.

Decision 5: how often you prove it

A backup that has never been restored is a hope. Testing has three levels and a cadence for each.

1. Restore tests: pick a VM, a database and a file share each month, restore them somewhere isolated, and check the data opens and the restore time is inside the RTO. Keep the log.
2. Failover drills for tier 1: fail the application over to the second region and run a real transaction through it, at least twice a year, with the business watching. Fail back afterwards and write up what broke.
3. Scenario exercises: once a year, walk through "the backup administrator's account is compromised" and "Central India is unavailable for two days" with the people who would actually act, and fix the gaps the walk-through finds.

RBI's Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, require regulated entities to define RTO and RPO for critical systems and to run disaster recovery drills at least half-yearly, and SEBI's and IRDAI's cyber frameworks also cover business continuity and disaster recovery. For everyone else the requirement comes from the board, the cyber insurer or the customer contract, and the evidence they ask for is the same.

• Documented RPO and RTO per workload, approved by the business. Where it comes from: Decision 2, signed
• The backup scope and the tool protecting each system. Where it comes from: Decision 1, the one-page inventory
• Proof the copies are off-site and in India. Where it comes from: Vault and plan configuration from decision 3
• Proof the copies cannot be destroyed by an administrator. Where it comes from: Immutability and separation settings from decision 4
• The last restore test and the last failover drill, with dates, durations and outcomes. Where it comes from: The test log from decision 5
• Alerting on backup failures and on changes to protection. Where it comes from: Monitoring configuration; our monitoring and operations service covers this with the rest of the estate

The cost traps

Backup can grow faster than almost any other line on a cloud bill, for reasons that have little to do with how much data is protected.

• Protected-instance fees. Azure Backup charges per protected VM each month, tiered by size, before any storage; a stopped-but-not-deleted VM still pays it. Review the protected list quarterly and remove the machines that no longer exist or no longer matter.
• Snapshot sprawl. Manual snapshots taken before a change and never deleted accumulate on every platform; they are charged per gigabyte and are not part of any retention policy. A lifecycle rule or a monthly report on snapshots older than 30 days with no tag is the fix.
• Geo-redundancy for everything. Doubling the storage for tier 3 workloads buys nothing. Apply the second region to the tiers that need it.
• Retention nobody chose. Default long-term retention of years, on data the DPDP Act will require you to erase once its purpose is served (from 13 May 2027, after the Rules' one-year minimum), costs money and creates a compliance problem at the same time; our DPDP checklist covers aligning backup retention with erasure.
• Cross-region charges. AWS and Google Cloud bill data transfer between regions per GB, and Azure's Cross Region Restore raises vault storage to a higher (RA-GRS) rate; the restored copy bills from the first hour, and a DR drill that restores 20 TB has a visible cost. Budget it rather than discovering it.
• Test environments left running. The failover drill stands up a second copy of production. The copy that was never shut down afterwards keeps billing until someone notices.

Where backup spend goes in an illustrative 35-VM estate

• Backup storage, retained copies: 45%
• Protected-instance fees: 25%
• Geo-redundant second copies: 15%
• Orphaned snapshots: 10%
• DR test environments left running: 5%

The last three items, 30% of the line in this illustration, can often be reduced without protecting anything less. The storage section of our Cloud Cost Audit Checklist has those checks, with where to look on each platform.

Where CloudSwift fits

Our backup and disaster recovery service is built around the five decisions above: the scope inventory and the tiering with the business first, then the vault, replication, immutability and separation configured per platform, then the monthly restore tests and the drills, with the evidence table kept current for the auditor. For banks and financial institutions the same work is aligned to the RBI directions from the start, so the drill record and the RTO evidence exist before the inspection asks for them.

If you are not sure what your recovery time actually is, book a consultation. The first conversation is the scope inventory.

Frequently asked questions

Is cloud backup automatic on Azure, AWS and Google Cloud?

No. Each platform offers a backup service and some managed databases take short-lived automated backups, but nothing protects a VM, a storage account or a SaaS platform until someone configures it, and the defaults for retention, redundancy and immutability are the minimum, not the standard.

What is the difference between backup and disaster recovery?

Backup is a copy you restore from, measured in hours of recovery. Disaster recovery is a second environment you fail over to, measured in minutes to a few hours. Tier 1 workloads need the second; most of the estate needs only the first. Paying for failover everywhere is as common a mistake as having it nowhere.

Which Indian regions should hold the second copy?

On Azure, Central India and South India are a designated pair, and India South Central pairs with Central India. On AWS, Mumbai and Hyderabad; on Google Cloud, Mumbai and Delhi. All three keep both copies in India, which meets Indian residency requirements where they apply and keeps restore traffic domestic.

How do we protect backups from ransomware?

Make the copies immutable for the retention period, using the platform's locked vault or retention lock, and keep them in a separate subscription, account or project that production credentials cannot reach. Extend soft delete beyond the default, alert on any change to protection, and test that a restore works from the immutable copy.

What does a bank's auditor ask to see?

Documented RPO and RTO per workload, the backup scope and tooling, proof the copies are off-site and in India, the configuration that stops an administrator deleting them, and the dates and outcomes of the last restore tests and failover drills. The five decisions in this article produce exactly that evidence.