Backups and Disaster Recovery in Azure: What your company should consider

A recovery strategy in Azure should combine backups, replication, security, region-based recovery, and periodic testing. Azure Backup protects data and recovery points; Azure Site Recovery maintains replicated workloads and orchestrates failover. The architecture should be defined based on RTO, RPO, criticality, compliance, and the financial cost of downtime.

Taxonomic definitions

1. Azure Backup. Managed service from Microsoft to protect data and workloads through backup, retention, and recovery policies. You can protect Azure resources and on-premises environments, including virtual machines, files, disks, databases, blobs, AKS, and certain on-premises servers.

2. Azure Site Recovery. Continuity service that replicates workloads from a primary site to a secondary location. It allows for failover, temporary operation from the destination, and failback when the original site becomes available again.

3. RTO and RPO

RTO — Recovery Time Objective: Maximum time a process or system can remain unavailable.
RPO — Recovery Point Objective: Maximum amount of data that the business can accept to be lost, measured in time.
Example: A two-hour RTO requires recovering the operation within that period; a 15-minute RPO requires that the loss of information not exceed approximately the last 15 minutes.

RTO and RPO should not be defined by technical preference. They should be derived from the financial, operational, contractual, and regulatory impact.

Comparison table: Backup, Disaster Recovery and High Availability

Variable	Azure Backup	Azure Site Recovery	High availability
Objective	Recovering data or systems from previous points	Maintaining a replica and recovering the operation in another location	Avoid or reduce interruptions caused by local failures
Protects against	Deletion, corruption, ransomware, errors and loss of information	Site collapse, region, infrastructure or machinery	Instance, host or zone failure, depending on architecture
Mechanism	Copies and recovery points	Replication, failover, and failback	Active redundancy, balancing and distribution
RPO	It depends on the frequency and backup technology	It can be low through continuous replication	Close to zero in suitable architectures
RTO	It depends on the restoration time	Designed for orchestrated recovery	Generally lower for contemplated defects
Historical recovery	Yes	Limited to available replication points	It is not their primary function
Long-term retention	Yes	It does not replace backup retention	No
Tests	Controlled restoration	Failover simulations without interrupting replication	Availability and switching tests
Use case	Recover files, databases, VMs, or previous versions	Recovering an application or entire environment	Maintaining an operational service in the event of failure
Risk if used alone	Restoration too slow for the business	Replica errors, corruption or attacks if there is no backup	It does not protect historical versions or logical deletions

Why a backup is not a Disaster Recovery Plan

A backup answers the question:

Can we recover the data or the system?

A disaster recovery plan answers additional questions:

In how long?
With how much data loss?
In what infrastructure?
In what order should the components be recovered?
How will users access it?
What will happen to the identities?
How will the traffic be redirected?
Who authorizes the failover?
How will the integrity be validated?
How will the incident be communicated?
How will the operation return to the main site?

Microsoft explicitly differentiates between these two capabilities: Azure Backup retains recoverable data, while Azure Site Recovery replicates workloads and allows for switching to a secondary location during an outage.

A company can have successful backups and still fail to meet its RTO. It can also have a replica available, but lack a clean version prior to the attack. Therefore, backup, replication, and high availability must operate as complementary layers.

1. Start with a Business Impact Analysis

Before creating vaults, policies, or replicas, the company must identify:

Critical processes.
Applications that support them.
Affected users.
Technological departments.
Funds committed.
Contractual penalties.
Regulatory obligations.
Reputational impact.
Alternative manual labor.
Maximum tolerable time of interruption.
Data that cannot be reconstructed.
Necessary sequence for recovery.

Suggested classification

Level 1: critical mission

Payment processing.
Sales channels.
Clinical systems.
Plant operation.
Digital banking.
Financial ERP in shutdown.
Identity and authentication.
Transactional integrations.

These services usually require demanding RTO and RPO, replication, automation, and frequent testing.

Level 2: critical for operation

Collaboration tools.
Departmental applications.
Internal portals.
Operational repositories.
Logistics systems.
Service platforms.

They can accept moderate periods of unavailability, but they need documented procedures.

Level 3: recoverable

Historical archives.
Unproductive environments.
Reproducible information.
Systems with manual, time-consuming processes.
Data not urgent for consultation.

They can use longer retention periods and recovery on demand.

Treating all charges as Level 1 unnecessarily increases the cost. Treating all charges as Level 3 exposes the EBITDA.

2. Defining RTO and RPO with business figures

To calculate the RTO

Consider:

Income per hour.
Contribution margin.
Unproductive payroll.
Penalties.
Operations not processed.
Affected customers.
Contingency costs.
Regulatory requirements.
Reputational damage.
Accumulated effect on other processes.

Guideline formula:

Cost per hour of interruption × hours of recovery

To calculate the RPO

Determine:

How many transactions are generated per minute.
What data can be reconstructed.
What information depends on third parties.
How much it costs to reconcile it.
What records have legal value.
What loss would fines or non-compliance cause?.
How much work would have to be repeated.

A zero RPO has very different architectural and economic implications than a 24-hour RPO. The decision must be justified by impact, not with phrases like “everything is important”.

3. Mapping the workloads

Azure Backup can protect different sources, including:

Windows and Linux virtual machines.
Azure Managed Disks.
Azure Files.
SQL Server on Azure VMs.
SAP HANA on Azure VMs.
PostgreSQL.
Azure Blobs.
Azure Kubernetes Service.
Azure Data Lake Storage.
On-premises archives, folders, and servers using compatible components.

The company must confirm for each shipment:

Compatibility.
Consistency of application.
Frequency.
Retention.
Size.
Speed of change.
Estimated time for restoration.
Departments.
Region of origin.
Recovery Region.
Encryption requirements.
Need for granular restoration.
Need for complete recovery.

4. Designing the architecture of Azure Backup

Choosing the right vault

Azure uses vaults to store:

Protected copies.
Recovery points.
Policies.
Metadata.
Work history.
Backup configuration.

The types and compatibilities vary depending on the protected source. Not all workloads use exactly the same vault type.

Choosing redundancy

Microsoft documents three main options:

LRS — Locally Redundant Storage: It maintains several copies within the region and offers the lowest relative cost.
ZRS — Zone-Redundant Storage: It replicates data between availability zones within the same region.
GRS — Geo-Redundant Storage: It replicates the data to a secondary region.

For production workloads, the Microsoft reliability guide recommends using ZRS as the minimum level when available. When GRS is used, Cross Region Restore should be evaluated to restore in the paired region without relying exclusively on a formal disaster declaration.

Design precaution

The redundancy of the backup must be defined before protecting workloads, because certain configurations are locked after protection starts. Changing them later may require a new vault, reassignment, and additional activities.

5. Designing Azure Site Recovery

Azure Site Recovery can replicate:

Virtual machines between Azure regions.
VMware towards Azure.
Hyper-V to Azure.
Compatible physical servers.
Certain workloads from Azure Stack or hybrid environments.

Elements that must be defined

Primary region.
Secondary region.
Virtual recovery network.
Subnetworks.
IP addresses.
DNS.
Load balancers.
Safety rules.
Identities.
Administrative access.
Computing capacity.
Quotas.
Storage.
External departments.
Connectivity with on-premises.
Start order.
Scripts.
Validations.
Failback procedure.

Recovery plans

Recovery plans allow:

Group machines together.
Defining sequences.
Separate application layers.
Insert manual actions.
Running scripts.
Integrate with Azure Automation.
Coordinate multi-layer application recovery.

An application is not recovered simply by turning on machines. First, identity, network, database, middleware, integrations, and finally the user layer may be required.

Replication and objectives

Azure Site Recovery offers continuous replication for certain scenarios. Microsoft documents frequencies of up to 30 seconds for Hyper-V and the ability to reduce times through integration with traffic management services. Actual results depend on load, network, region, architecture, and testing.

6. Protect backups from ransomware

A connected backup that is managed with the same compromised identities can be deleted or modified by an attacker.

Architecture must include several layers.

Data isolation

Azure Backup stores protected data in isolation from the production environment. External or guest users do not have direct access to the managed storage where the backups reside.

Soft delete

Soft delete delays permanent deletion and allows you to recover information that has been deleted accidentally or maliciously.

Microsoft states:

14-day default retention.
Possibility of extending it to 180 days.
Protection against elements and vaults in compatible stages.

Immutability

An immutable vault blocks operations that could remove recovery points or reduce their retention.

The configuration can:

To become competent.
Locking yourself in.
Becoming irreversible.
Use WORM storage when available.

Microsoft notes that the irreversible lock must be applied after carefully validating the operational impact, because it prevents the immutability from being disabled later on.

For organizations in Mexico, Microsoft includes Mexico Central among the regions with general availability of WORM storage for immutable and locked Recovery Services vaults, subject to the compatible workloads indicated by the service.

Multi-user authorization

Multi-User Authorization uses Resource Guard to require additional authorization for critical operations.

The recommended design separates:

Administrator of the vault.
Owner of Resource Guard.
Permits for sensitive operations.
Subscription or tenant, when greater isolation is needed.

Resource Guard can protect actions such as:

Eliminate protection.
Reduce retention.
Disable soft delete.
Change encryption.
Disable immutability.
Remove your own MUA protection.

Encryption

Backups are encrypted by default with keys managed by the platform. In scenarios requiring direct key control, client-managed keys can be used using Azure Key Vault, subject to compatibility and configuration requirements.

7. Separating functions and privileges

They must at least be distinguishable:

Production manager.
Backups administrator.
Security Administrator.
Responsible for Resource Guard.
Failover approver.
Business manager.
Auditor.
Incident response team.

A single account with permissions to manage production, delete backups, modify retention, and run failover represents a concentration of risk.

8. Test the recovery

A successful backup demonstrates that the work is complete. It does not demonstrate that the application can operate.

The testing program should include:

Restoration of files.
Recovery of databases.
Restoring a VM.
Recovery in isolated network.
Validation of integrity.
Authentication tests.
Connectivity with departments.
Application tests.
Failover simulation.
Proof of failback.
Measurement of the actual RTO.
Measurement of the actual RPO.
Documentation of deviations.

Azure Site Recovery allows you to run simulations without affecting the ongoing replication. This makes it easier to validate the plan without stopping the production environment.

Suggested frequency according to criticality

Critical mission: quarterly or when there are relevant changes.
Criticism: semestral.
Recoupable: annual.
Modified components: after architectural changes.
Controls against ransomware: after identity changes, security or retention.

The final frequency must be defined according to regulations, contracts, and the level of risk.

9. Designing observability and alerts

The company must monitor:

Failed jobs.
Cargo without protection.
Reproduction delays.
Recovery points.
Changes in policy.
Reduction of retention.
Eliminations.
Deactivation of controls.
Health of the vault.
Capacity.
State of agents.
Azure Service Health events.
Pending tests.
Exceptions to the RTO or RPO.

Azure offers centralized monitoring, alerts, and integration with Azure Monitor to expand reporting and monitoring capabilities.

10. Consider shared responsibility

Microsoft operates the infrastructure of the service, but the company remains responsible for:

Classifying loads.
Select redundancy.
Configure policies.
Define retention.
Enable Cross Region Restore.
Protecting identities.
Configure immutability.
Establish MUA.
Try restorations.
Designing dependencies.
Validate the RTO and RPO.
Maintain procedures.
Making the failover decision.

Microsoft describes reliability in Azure as a shared responsibility: the platform provides capabilities, but the customer must select and configure the necessary ones to meet their business objectives.

11. Building the financial case

Technological costs

Protected instances.
Storage capacity.
Retention.
Redundancy.
Secondary region.
Computation during tests.
Replication.
Connectivity.
Supplementary licensing.
Observability.
Operation administered.

Government costs

Tests.
Documentation.
Auditing.
Change management.
Training.
Simulacros.
Update of the plan.
Response to incidents.

Financial benefits

Hours of unavailability avoided.
Preserved transactions.
Avoided penalties.
Reduction in recovery effort.
Less dependence on manual processes.
Protection of income.
Continuity of production.
Lower reputational impact.
Evidence of compliance.

Evidence of impact

In a case documented by Scanda, the implementation of a recovery plan with two hyperscalers reduced the time required to restore critical services after a major disaster from 48 to 12 hours. This equates to 36 hours less downtime and a 75% reduction in the previous recovery time.

The financial value of those 36 hours must be calculated based on:

Income per hour.
Margin.
Affected users.
Production stopped.
Penalties.
Operations not processed.
Cost of recovery.
Contractual and reputational damage.

The important data is not simply “recovering in 12 hours”. It is demonstrating what processes can be restored, with what integrity, what loss of information and what residual economic impact.

Mistakes that the company should avoid

Confusing replication with backing. Replication can copy corruption, malicious encryption, or deletions. Protected historical points are required.
Keep everything in a single region. A regional architecture without secondary strategy may be insufficient for the agreed RTO.
Not protecting the management plan. If the attacker compromises administrative identities, they may attempt to disable controls or remove recovery points.
Defining RTO and RPO without the business. You can estimate technical times, but Finance, Operations, Risk, and Compliance must determine the actual tolerance.
Not including dependencies. A recovered VM is useless if it lacks DNS, identity, database, integration, or connectivity.
Do not try failback. Recovering in the secondary region is only half the process. The organization must know how to return to normal operation.

Measuring only successful backups

The relevant indicators are:

Real recovery capacity.
Real-time restoration time.
Real data loss.
Compliance with the RTO.
Compliance with the RPO.
Integrity of the application.
Evidence of the simulation.

The role of Scanda

Scanda helps build resilience, not just a backup configuration.

The service may include:

Business Impact Analysis.
Application classification.
Definition of RTO and RPO.
Azure assessment.
Backbone architecture.
Site Recovery design.
Redundancy configuration.
Cross Region Restore.
Immutability.
Resource Guard.
Identity checks.
Recovery plans.
Automation.
Simulacros.
Executive boards.
Documentation.
Government continues.
Cost optimization.
Accompanying an Outcome Owner.

Scanda positions continuity as a measurable business outcome: availability, recovery time, residual risk, cost of interruption, and evidence for management or audit.

Predictive conclusion

Isolated backup will no longer be sufficient for organizations subject to ransomware, distributed operations, and growing digital dependencies. Mature architectures will combine historical recovery, replication, immutability, multi-user authorization, function segregation, and evidence-based simulations.

The advantage will not be “having Azure”; it will be demonstrating that the company can recover critical processes within approved financial limits. Organizations that do not measure their actual RTO and RPO will discover the gap during the incident, when every hour becomes more expensive and there is less room to correct it.

FAQ

1. Are Azure Backup and Azure Site Recovery the same thing? No. Azure Backup retains historical copies and points for restoring data or systems. Azure Site Recovery replicates workloads and orchestrates failover to another location. A complete strategy may require both services.

2. How should a company define its RTO and RPO? It should be based on the Business Impact Analysis. The RTO is defined by how long the process can be held up. The RPO is defined by how much data the company can lose without causing an unacceptable impact.

3. Does Azure alone guarantee that the company can recover? No. Azure provides backup, replication, redundancy, and security capabilities, but the company must configure them, protect them, integrate them with its applications, and test them periodically.

Does your company have backing or can it prove that it will actually recover?

Scanda can evaluate:

What processes require Disaster Recovery.
What loads are unprotected.
If the RTO and RPO are financially correct.
How long would a real restoration take?.
If the supports withstand an attack.
Which departments are not included.
What region needs redundancy and retention.
How much does it cost to maintain the architecture?.
Which tests must be performed?.

Schedule an executive session with Scanda to turn your backups and Azure services into a proven capability of business continuity, security, and resilience.