India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Google Cloud Backup, Disaster Recovery & Regional Resilience
Google Cloud backup and resilience is the combination of Backup and DR Service vaults, database point-in-time recovery, synchronous zonal replication and cross-region replicas that lets a workload survive deletion, ransomware, a zone loss or a region loss. NTSPL designs and drills these patterns between Mumbai and Delhi for Indian payments, SaaS and manufacturing teams with stated RPO and RTO targets.
Google Cloud services in scope
The Problem Backup and DR Service with backup vaults and Backup and DR management console and backup/recovery appliance Solve
Teams that move to Google Cloud often assume resilience comes free because the platform is redundant. It does not. A zonal persistent disk dies with its zone; a Cloud SQL instance without high availability has a single primary; a snapshot in the same project can be deleted by the same compromised admin who encrypted the data. And regulated Indian workloads add a constraint many global templates ignore: the asia multi-region spans countries outside India, so payment and lending data cannot simply be copied there. The real problem is matching each failure mode, from accidental DROP TABLE to a full asia-south1 outage, with a control that is isolated, tested and India-resident.
NTSPL works from a failure-mode table, not a product list. For each application we agree an RPO and RTO for four events: logical corruption, ransomware, zone failure and region failure. Then we place the control: regional persistent disks or Hyperdisk Balanced High Availability for zones, Cloud SQL or AlloyDB replicas in asia-south2 for regions, and Backup and DR vaults with enforced retention in a separate project for ransomware. Every design ends with a timed restore drill whose log becomes audit evidence.
When to Invest in Backup and DR Vaults, Database Replicas and Mumbai-Delhi Failover
Signals that point to backup & resilience on Google Cloud
- Your last restore test was more than six months ago, or nobody can state the RTO of the core database from evidence.
- Snapshots live in the same project, under the same admins, as the production disks they protect.
- An RBI, SEBI or IRDAI inspection or a customer contract asks for a documented DR site, drill reports and India-only data residency.
- A single-zone Cloud SQL instance or VM already caused an outage during a Google Cloud zonal maintenance or incident.
- Cyber insurance renewal asks whether backups are immutable and logically separated from production credentials.
- Monthly snapshot spend keeps climbing because nobody owns retention and expiry across hundreds of disks.
When a different approach is better
- If the workload is fully stateless containers rebuilt from Artifact Registry images and Terraform, backing up VMs adds cost without value; protect only the data stores and the pipeline definitions.
- If you need continuous replication of on-prem VMware VMs with failover into Google Cloud, start with Google Cloud VMware Engine and its DR tooling rather than native Compute Engine backups.
- If data must be retained for 10 years for archives but never restored quickly, a Cloud Storage Archive class bucket with Bucket Lock is cheaper than long vault retention.
Google Cloud Resilience Building Blocks: Backup and DR Service, Cloud SQL, AlloyDB, Regional Disks and Hyperdisk
| Service | Role in the architecture | Choose it when |
|---|---|---|
| Backup and DR Service with backup vaults | Takes policy-driven backups of Compute Engine instances and disks, Cloud SQL, AlloyDB and Filestore into Google-managed backup vaults whose enforced minimum retention prevents early deletion, even by a Project Owner. | You need ransomware-resistant copies that a compromised administrator in the workload project cannot delete or shorten. |
| Backup and DR management console and backup/recovery appliance | Protects application-consistent databases such as SQL Server, Oracle and SAP HANA, plus VMware Engine VMs, using an appliance that captures incremental-forever backups and supports mount-and-migrate restores. | You run self-managed databases on Compute Engine that need transaction-log capture and fast instant mounts rather than disk-level snapshots. |
| Cloud SQL high availability, point-in-time recovery and cross-region read replicas | Combines a synchronous standby in a second zone, write-ahead or binary log retention for point-in-time recovery, and asynchronous read replicas in another region that can be promoted. | Your PostgreSQL, MySQL or SQL Server database needs zone-loss survival with no data loss and a warm copy in Delhi for regional events. |
| AlloyDB for PostgreSQL continuous backup and cross-region secondary clusters | Keeps continuous backup for point-in-time recovery to any second within the configured window and replicates to a secondary cluster in another region that can be promoted to primary. | A high-write PostgreSQL workload needs lower replication lag and faster regional promotion than a Cloud SQL read replica gives. |
| Regional Persistent Disk and Hyperdisk Balanced High Availability | Synchronously replicates block storage across two zones of the same region so a VM can be force-attached to the surviving zone with zero data loss. | A stateful VM such as a file server, licence server or legacy application cannot be made stateless and must survive a zonal outage. |
| Cloud Storage Bucket Lock and Object Retention Lock | Applies a retention policy at bucket or object level that blocks deletion or overwrite until the retention period expires, with soft delete as an extra recovery window. | Exports, invoices, ledger snapshots or database dumps must be provably immutable for a regulatory or contractual period. |
Mumbai primary, Delhi recovery design with isolated backup vaults
Mumbai primary, Delhi recovery design with isolated backup vaults
Production runs in asia-south1 across two zones with Cloud SQL or AlloyDB in high availability and stateful VMs on regional disks. Changes replicate asynchronously to asia-south2, while Backup and DR Service writes scheduled backups into vaults in a separate backup project with enforced retention, giving three independent recovery paths for zone, region and ransomware events.
Select any component
Mumbai primary, Delhi recovery design with isolated backup vaults: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Resilience Engineering Decisions: RPO/RTO Tiers, Vault Placement, Retention Lock and Region-Pair Failover
RPO and RTO tiers mapped to controls
We define three tiers. Tier 1 (payments, order capture) gets zonal HA plus a cross-region replica: RPO under one minute and RTO under 30 minutes for a region event. Tier 2 (back-office, reporting) relies on vault backups restored into Delhi: RPO of one to four hours, RTO of four to eight hours. Tier 3 (dev, analytics sandboxes) gets daily backups only. Writing the tiers down stops every team from demanding Tier 1 and doubles nobody's bill unnecessarily.
Where to place backup vaults for India-resident data
Backup vaults can be regional, cross-regional or multi-regional, but the asia multi-region includes locations outside India, so for RBI-regulated payment data or DPDP-sensitive records we use regional vaults only. Compute Engine and Filestore backups go to a cross-region vault in asia-south2 to survive a Mumbai event. Cloud SQL and AlloyDB vaults must sit in the source region, so their regional resilience comes from cross-region replicas, not from the vault. We document this split explicitly because auditors often assume one vault covers everything.
Enforced retention and retention lock timing
Enforced minimum retention can be set from 1 day to 99 years; once retention lock passes its effective date, the minimum can only increase. We set the vault minimum to the shortest legitimate retention, typically 14 to 30 days, and let backup plans hold longer copies. We schedule the lock date two to four weeks after go-live, after one successful restore drill, because a mistaken 7-year lock on hourly backups becomes an irreversible storage bill.
Cloud SQL replica versus AlloyDB secondary for regional failover
Cloud SQL Enterprise Plus with a cross-region replica suits databases below a few thousand writes per second where lag stays in seconds; its DR replica can be switched over and later switched back. AlloyDB's secondary cluster suits heavier write loads and analytical reads in Delhi, and promotion is quick. For SQL Server we prefer Cloud SQL replicas over self-managed Always On unless the application needs features Cloud SQL lacks. In all cases we alert when replication lag exceeds the tier's RPO.
Zonal resilience for stateful VMs
Regional Persistent Disk and Hyperdisk Balanced High Availability give synchronous two-zone replication with zero RPO, at roughly double the disk cost and some extra write latency. We use them for licence servers, file shares and legacy apps, but not for databases that already replicate at the application layer, where double replication only adds latency. Failover is a force-attach to a pre-created standby VM, which we script and time; typical measured RTO is 5 to 10 minutes.
How NTSPL Builds and Drills a Mumbai-Delhi Recovery Design
Failure-mode workshop
Agree RPO and RTO per application for four failure events and assign each application to a protection tier with business sign-off.
Isolated backup project and vaults
Create a backup project with separate admins, regional vaults in asia-south1 and asia-south2, and access restricted to the organization.
Backup plans and associations
Attach Compute Engine, Filestore, Cloud SQL and AlloyDB resources to tiered backup plans and verify first full backups complete.
Database replica build
Create Cloud SQL cross-region replicas or AlloyDB secondary clusters in Delhi and baseline replication lag under peak load.
Failover and restore drill
Run a timed drill: restore from vault, promote the Delhi replica, switch Cloud DNS, then switch back, measuring actual RPO and RTO.
Retention lock and handover
Apply retention lock after a clean drill, hand over runbooks and schedule quarterly drills in the operations calendar.
What you receive
Protecting Backups from the Attacker: Vault Isolation, Enforced Retention and Restore-Only Roles
Ransomware operators now delete or encrypt backups before they encrypt production. The defence on Google Cloud is separation: vaults in a project the workload admins cannot administer, enforced retention that even a Project Owner cannot shorten after lock, access restriction so only the organization's resources can back up or restore, and a restore role held by a small group with Privileged Access Manager elevation. Backup data in vaults is managed by Google and cannot be read directly by users.
- Enforced minimum retention with retention lock so no identity can delete backups early
- Vault access restriction set to current organization so outside projects cannot restore data
- Separate backup project with Backup and DR admin roles not granted to workload admins
- Project lien on the backup project to block accidental or malicious project deletion
- Audit log alerts on backup plan deletion, plan association removal and vault policy changes
What Backup and DR Costs on Google Cloud: Protected Data, Vault Storage, Replica Instances and Cross-Region Transfer
Backup and DR Service bills for the protected resource size and for backup storage consumed in the vault, with storage charges driven by change rate and retention length. Database resilience costs are replica instance hours and storage in asia-south2 plus cross-region replication traffic. Regional disks cost about twice zonal disks. The biggest waste we find is identical retention for every disk and full-size idle replicas for Tier 2 systems.
- Tier retention: 7 to 14 days of hourly points for Tier 1, daily points for Tier 2, weekly for Tier 3
- Size Delhi read replicas for replication and read traffic, then resize at promotion instead of mirroring the primary
- Exclude scratch and temp disks from backup plans by label
- Use committed use discounts for the Mumbai primary database and keep the Delhi standby on on-demand pricing
- Move long-term compliance copies to Cloud Storage Archive with Bucket Lock rather than holding years of vault backups
Snapshots vs Backup and DR vaults vs cross-region replicas: which protects against what on Google Cloud?
Each protects a different failure, so a serious design uses at least two. Logical corruption: Cloud SQL or AlloyDB point-in-time recovery and vault backups both let you rewind; replicas do not, because they copy the corruption within seconds. Ransomware and insider deletion: only vault backups with enforced retention in a separate project are reliably out of the attacker's reach; standard snapshots in the workload project can be deleted by its owner. Zone loss: regional disks and HA database configurations recover in minutes with zero data loss. Region loss: cross-region replicas give the lowest RTO; cross-region vault backups are cheaper but slower to restore. Choose replicas for Tier 1, vaults for everything.
Key facts about backup & resilience on Google Cloud
Backup & Resilience on Google Cloud in Practice
3 backup & resilience scenarios from Payments, payment aggregator and gateway, Software as a service, accounting and GST compliance, Aerospace and defence manufacturing: the starting position, the services chosen, the architecture, the rollout and the measured outcome.
Payment gateway reaches a 22-minute regional failover between Mumbai and Delhi
Accounting SaaS makes ledger backups immune to admin compromise with locked vaults
Aerospace components maker protects its PLM vault with 1-hour restore points
Retail chain moves SAP S/4HANA retail landscape to Google Cloud before peak season
Paints manufacturer gets 4-minute HANA failover and in-country DR on Google Cloud
Digital lending app removes 96 service account keys ahead of its NBFC partner's RBI audit
Backup & Resilience on Google Cloud: Frequently Asked Questions
How is Google Cloud Backup and DR Service priced?
It charges on two main dimensions: the size of the protected resources and the backup storage consumed in vaults, which depends on change rate and retention. Cross-region vaults add network transfer. For a typical mid-size estate of 40 VMs and 6 TB of protected disks with 30-day retention, NTSPL usually sees INR 60,000 to 1.4 lakh per month, before database replica costs, which are billed as normal Cloud SQL or AlloyDB instances.
We back up on-prem with a commercial backup tool. How do we move to Google Cloud?
Run both until the first clean drill. NTSPL protects migrated workloads with Backup and DR Service from day one of cutover, keeps the on-prem tool's last full backup as a fallback for the agreed retention period, and only then decommissions it. For SQL Server or Oracle on Compute Engine, the Backup and DR appliance gives application-consistent backups with log capture comparable to on-prem tools.
Can we keep backups and DR entirely inside India?
Yes, by using only regional and cross-regional locations in asia-south1 Mumbai and asia-south2 Delhi and avoiding the asia multi-region, which includes locations outside India. NTSPL enforces this with an Organization Policy resource-location constraint so no vault, bucket or replica can be created elsewhere. This matters for RBI payment data localisation and for DPDP-sensitive datasets.
What RPO and RTO can we realistically get between Mumbai and Delhi?
For databases with cross-region replicas, RPO is usually seconds to under a minute, driven by replication lag, and RTO of 15 to 30 minutes including promotion, DNS switch and application scale-out. For workloads recovered from vault backups, RPO equals your backup interval and RTO is typically two to eight hours depending on data size. NTSPL states these only after a timed drill.
Do vault backups protect us if an attacker gets Owner on our production project?
Yes, if the vault is in a separate project and enforced retention is locked. The attacker can stop new backups or delete production, but cannot delete existing backups before their retention expires or change the locked minimum. NTSPL also alerts on backup plan changes so a disabled schedule is noticed within minutes, not at the next audit.
How often should we test disaster recovery?
At least quarterly for Tier 1 systems, and after every major schema or topology change. NTSPL runs one full regional failover per year and smaller restore tests monthly, such as restoring a random VM backup into an isolated project. Regulators such as RBI and SEBI expect periodic DR drills with documented results, so each drill produces a timestamped report.