India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Azure Backup & Site Recovery Disaster Recovery Services
Azure Backup is Microsoft's managed backup service that stores point-in-time recovery copies of VMs, databases, files and disks in Recovery Services or Backup vaults, while Azure Site Recovery continuously replicates servers for failover to another region. NTSPL designs immutable, ransomware-resistant backup and tested Site Recovery runbooks for Indian businesses that need proven RPO and RTO, not just a backup schedule.
Microsoft Azure services in scope
The Problem Azure Backup (Recovery Services vault) and Azure Backup vault Solve
Backup and DR fail in two predictable ways. The first is ransomware: attackers who gain admin rights now delete backups before encrypting production, so a vault that an administrator can purge is no protection at all. The second is untested recovery: replication shows green in the portal for two years, then the first real failover discovers that the DR virtual network has no route to the database, DNS still points to the primary, and the ERP licence server binds to a MAC address. Neither problem is solved by buying more storage. Both are solved by vault configuration, recovery-plan engineering and drills that are actually run.
NTSPL begins by classifying each workload into recovery tiers with a business-signed RPO and RTO, then designs the protection per tier: Azure Backup policies with immutable vaults and multi-user authorization for every tier, plus Azure Site Recovery replication with recovery plans for systems that cannot wait for a restore. We pick region pairs deliberately, typically Central India primary with South India as recovery, and every engagement ends with a timed test failover whose actual RPO and RTO are recorded in the handover report.
When Azure Backup and Site Recovery Fit Your Recovery Targets (and When Native Replication Is Better)
Signals that point to backup & disaster recovery on Microsoft Azure
- You cannot state the last date a full DR failover was tested end to end, with application sign-off.
- Your backup administrator can delete recovery points or vaults without anyone else approving.
- On-premises backup tapes or a NAS in the same building are your only off-site copy.
- An auditor or regulator (RBI, SEBI, IRDAI, or a state IT department for public bodies) has asked for documented RPO and RTO and drill evidence.
- Your primary workloads are in one Azure region with no replication or geo-redundant backup.
- Restore requests for a deleted file or a corrupted database take more than a day because nobody knows which tool holds which copy.
When a different approach is better
- For stateless web tiers built from images or infrastructure-as-code, replicating VMs with Site Recovery wastes money; redeploy them in the DR region from pipelines and use Azure Front Door or Traffic Manager to shift traffic.
- Azure SQL Database and SQL Managed Instance already include automated backups and geo-replication via failover groups; adding Azure Backup for them is unnecessary, so configure long-term retention and failover groups instead.
- If you need near-zero RPO for a database, Site Recovery's crash-consistent replication is the wrong layer; use database-native replication such as SQL Server Always On availability groups or HANA System Replication.
Azure Recovery Building Blocks: Recovery Services Vaults, Backup Vaults, Site Recovery and Cross Region Restore
| Service | Role in the architecture | Choose it when |
|---|---|---|
| Azure Backup (Recovery Services vault) | Takes scheduled, application-consistent backups of Azure VMs, SQL Server and SAP HANA in VMs, Azure Files and on-premises servers through the MARS agent or MABS, with tiered retention. | You need daily-to-hourly recovery points with weeks-to-years retention and can tolerate a restore time measured in hours. |
| Azure Backup vault | Protects newer workload types such as Azure Blobs, Managed Disks snapshots, Azure Database for PostgreSQL flexible server and AKS clusters with operational and vaulted tiers. | Your protected estate includes blob data lakes, AKS persistent volumes or PostgreSQL flexible servers. |
| Immutable vaults, enhanced soft delete and multi-user authorization | Lock recovery points against deletion or retention reduction, keep deleted items recoverable for a configurable 14 to 180 days, and require a second tenant's Resource Guard approval for critical vault operations. | Ransomware is in your threat model, which in 2026 means always. |
| Azure Site Recovery | Continuously replicates Azure VMs between regions, or VMware, Hyper-V and physical servers into Azure, and orchestrates ordered failover through recovery plans with scripts and runbooks. | The business RTO is under 4 hours or RPO is under 1 hour for a system, which a restore from backup cannot meet. |
| Cross Region Restore | Allows restores from a geo-redundant Recovery Services vault into the Azure paired region at any time, not only after a Microsoft-declared regional outage. | You want a lower-cost regional DR option for tier-2 systems without paying for continuous replication. |
| Azure Business Continuity Center | Gives a single pane for protection status, jobs, policies and compliance across Azure Backup and Site Recovery, superseding Backup Center for at-scale management. | You operate more than a few vaults or subscriptions and need to find unprotected resources and failed jobs without opening each vault. |
Two-region recovery design with immutable backup
Two-region recovery design with immutable backup
Production VMs in Central India are backed up nightly or hourly into an immutable, geo-redundant Recovery Services vault and replicated continuously by Site Recovery to a pre-built recovery network in South India. During failover a recovery plan brings up the database, application and web groups in order, updates DNS and runs validation scripts, while Business Continuity Center and Azure Monitor alerts track protection health.
Select any component
Two-region recovery design with immutable backup: 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.
Recovery Engineering Decisions: Tiering, Indian Region Pairs, Immutability and Failover Networking
Backup vs replication by tier
Tier 1 (RTO under 4 hours, RPO under 30 minutes): Site Recovery plus daily Azure Backup, because replication protects against site loss but replicates corruption and ransomware too. Tier 2 (RTO 8 to 24 hours): Azure Backup with GRS and Cross Region Restore, no replication. Tier 3: locally redundant backup with 30-day retention. Most estates land around 15 percent tier 1, 35 percent tier 2 and 50 percent tier 3, which keeps Site Recovery licences limited to systems that justify them.
Region pairing in India
Central India (Pune) has availability zones and is our usual primary; its Azure paired region is South India (Chennai), which is where Cross Region Restore lands. Workloads in West India (Mumbai) also pair with South India. Site Recovery itself can target any region, so if an application must stay in a different seismic zone or closer to users we choose the target freely, but geo-redundant backup restores always go to the pair, so align both.
Immutability and deletion controls
Enable immutability on the vault in its reversible, not-yet-locked state first, run backups and restores for 2 to 4 weeks, then lock it, because locked immutability cannot be reversed. Set enhanced soft delete to at least 30 days, longer than typical attacker dwell time, and make it always-on. Put Resource Guard in a different subscription, ideally a different tenant, so compromise of the backup operator's identity is insufficient to destroy recovery points.
Application-consistent recovery
Crash-consistent snapshots are fine for web and file servers but risky for SQL Server, Oracle or Tally-style file databases. For SQL in VMs use Azure Backup's SQL workload backup with 15-minute log backups rather than VM snapshots. For Site Recovery, set app-consistent frequency to 1 hour on database VMs and validate that VSS writers succeed. For Linux databases, use pre and post scripts to quiesce the engine.
Failover networking and DNS
Most failed drills fail on networking, not replication. Pre-create the DR hub with firewall rules, VPN or ExpressRoute connectivity to branches and private DNS zones linked to the DR VNet. Decide early between retaining IP addresses (simpler for licensed apps, needs a full subnet failover) and changing IPs with DNS updates in the recovery plan. Keep TTLs at 300 seconds or less for any record the plan will change.
How NTSPL Builds and Proves an Azure Site Recovery Failover
Recovery tier register
Interview application owners and assign each workload an RPO and RTO tier, signed off by the business, which decides between backup-only and Site Recovery.
Vault build and hardening
Create Recovery Services vaults per environment with GRS or LRS by tier, private endpoints, CMK, enhanced soft delete and Resource Guard in a separate subscription.
Backup policy and auto-enrolment
Apply backup policies by tag through Azure Policy, use SQL and HANA workload backup for databases, and run restore tests before locking immutability.
DR landing zone in the target region
Pre-build the DR hub VNet, firewall rules, private DNS links and an isolated test-failover VNet in South India or the chosen target region.
Replication and recovery plans
Enable Site Recovery for tier-1 VMs, set app-consistent frequency, and author recovery plans with ordered groups and DNS and load-balancer runbooks.
Timed test failover and handover
Run a test failover with application owners verifying transactions, record actual RPO and RTO, fix defects, rerun, and lock in a drill calendar.
What you receive
Ransomware-Proofing Azure Backup: Immutable Vaults, Enhanced Soft Delete and Resource Guard
The adversary in backup design is an attacker holding backup-admin credentials. Recovery points must therefore survive a hostile insider or stolen identity: vault immutability prevents deletion and retention shortening, enhanced soft delete keeps deleted data recoverable, and multi-user authorization moves destructive operations behind a second approver. Replication traffic and vault data are encrypted, and restore operations are logged so an exfiltration attempt through restore-to-new-VM is visible.
- Locked immutable vault so no one, including Owner, can delete recovery points before expiry
- Always-on enhanced soft delete of 30 days or more to recover from vault or item deletion
- Resource Guard in a separate subscription for multi-user authorization on critical operations
- Private endpoints for Recovery Services vaults so backup and restore traffic stays off the internet
- Alerts on security-sensitive vault operations such as stop-protection and policy changes, routed to Sentinel
Azure Backup and Site Recovery Pricing: Protected Instances, Vault Redundancy and Replica Storage
Azure Backup bills a protected-instance fee per VM or workload, sized by protected data, plus backup storage consumed, with GRS costing roughly double LRS. Archive tier lowers long-term retention cost for monthly and yearly points. Site Recovery charges a monthly fee per replicated instance, with the first 31 days free, plus replica disk storage and compute only when VMs are actually failed over or tested.
- Use GRS and Cross Region Restore only for tier-1 and tier-2 vaults; LRS or ZRS for tier 3
- Move monthly and yearly recovery points older than 3 months to vault-archive tier
- Exclude temp, swap and scratch disks from both backup and Site Recovery replication
- Use Standard HDD or Standard SSD for Site Recovery replica disks where the failed-over performance allows
- Protect stateless tiers with infrastructure-as-code redeploy instead of paying Site Recovery per instance
Azure Backup vs Azure Site Recovery: do I need one, the other, or both?
Judge on four criteria. Purpose: Azure Backup gives historical recovery points to undo deletion, corruption or ransomware, keeping weeks to years of history; Site Recovery keeps a near-current replica to survive losing a region or data centre. RPO: Backup typically gives 15 minutes for SQL log backups and 24 hours for VMs; Site Recovery gives minutes. RTO: restoring a large VM can take hours; Site Recovery failover typically completes in minutes plus application start time. Corruption: Site Recovery replicates encryption and bad data within minutes, so it cannot replace backup. Conclusion: every production system needs Azure Backup. Add Site Recovery only where the business RTO is under about 4 hours or RPO under 1 hour, which is usually ERP, WMS, POS back-end and citizen-facing systems.
Key facts about backup & disaster recovery on Microsoft Azure
Backup & Disaster Recovery on Microsoft Azure in Practice
3 backup & disaster recovery scenarios from Third-party logistics and warehousing, Urban local body, Jewellery retail: the starting position, the services chosen, the architecture, the rollout and the measured outcome.
3PL operator cuts warehouse system recovery time from 2 days to 45 minutes
Municipal corporation keeps property-tax collection online through a DR event
Jewellery chain makes ERP and POS backups immune to ransomware deletion
Hospital group gives each unit ownership of its Azure bill with chargeback
API manufacturer moves a GxP-validated SAP landscape to Azure without re-validation delays
Agro-chemicals company gets tested SAP HA and DR during the kharif peak
Backup & Disaster Recovery on Microsoft Azure: Frequently Asked Questions
How is Azure Backup priced for a typical VM?
You pay a monthly protected-instance fee that depends on the size of data protected for each VM, plus the storage consumed by recovery points, charged per GB at LRS, ZRS or GRS rates. Incremental backups mean storage grows with change rate, not full copies. NTSPL sizes daily churn per server during assessment and gives an INR estimate per tier before you commit.
What RPO and RTO can Azure Site Recovery realistically achieve?
For Azure VM to Azure VM replication, crash-consistent recovery points are created about every 5 minutes, so RPO is typically a few minutes under normal churn. RTO depends on the recovery plan: VM boot is usually 5 to 15 minutes, and application start, DNS changes and validation add the rest. Well-engineered tier-1 plans NTSPL builds commonly finish within 30 to 60 minutes.
We back up on-premises servers to tape and a NAS today. How do we move to Azure Backup?
Start with the MARS agent for file and folder backup or Microsoft Azure Backup Server for Hyper-V, SQL and Exchange workloads, sending data to a Recovery Services vault in an Indian region. For large first copies, offline seeding avoids saturating the WAN. Keep tapes running in parallel for one retention cycle, then retire them once restore tests from Azure pass.
Will our backup and DR copies stay inside India?
Yes, if you choose Indian regions. A vault in Central India with geo-redundant storage replicates to its paired region, South India, and Site Recovery can target South India or Central India. All four Azure India regions, Central India, South India, West India and India South Central (Hyderabad, live since August 2026), are in-country, which supports data-localization expectations from RBI for payment data and residency choices under the DPDP Act.
Can ransomware encrypt or delete our Azure backups?
Not if the vault is configured correctly. Azure Backup data is not reachable as a file share from production VMs, so ransomware cannot encrypt it directly. To stop an attacker with admin credentials, lock the vault as immutable, keep enhanced soft delete always-on and protect destructive operations with Resource Guard multi-user authorization in a separate subscription.
How often should Azure Site Recovery test failovers run, and do they affect production VMs?
Run a Site Recovery test failover at least twice a year for tier-1 systems, and after any major application change. Test failover brings VMs up in an isolated VNet from replicated data while replication continues, so production is unaffected. NTSPL times each step, has application owners sign off functionality, and cleans up the test environment the same day to avoid compute charges.