Rentals
Shop Online

Azure Arc Services:

Microsoft Azure Backup & Disaster Recovery

When systems go down, what matters isn’t whether your data was saved to a vault. It’s whether your applications can resume and your customers can keep working, in minutes rather than days. That requires a different kind of preparation.
Braintree designs and operates Azure Backup and Disaster Recovery solutions that protect both: the data and the business that depends on it.
Talk to a Recovery Specialist
Download the BCDR Guide
The assumption that’s leaving organisations exposed
When something goes wrong: two scenarios
Recovery is a design outcome, not a backup policy
Azure Backup and Disaster Recovery, implemented properly
Designed for real conditions, not ideal ones
Downtime is a risk you’re already carrying
FAQs
azure backup header e1773654270500 | Braintree

The assumption that’s leaving organisations exposed

Most IT teams can point to a backup policy. Azure Backup is configured, a Recovery Services Vault exists, snapshots are running on schedule. It feels like resilience.
But data protection and operational recovery are not the same thing. Backups capture information at a point in time. They do not guarantee that systems, applications, integrations, and customer-facing services can be restored under real-world conditions.
The gap shows up at the worst possible time: when a cyber incident, infrastructure failure, or accidental deletion forces the question. Teams that assumed they were covered discover they’re rebuilding and not recovering.
100 | Braintree

of reporting South African companies disclosed revenue loss due to downtime in 2025

86 hours | Braintree

lost per year, on average, to IT outages per South African enterprise

100 | Braintree

in direct losses from a single cyber breach over three years

Figures based on reported disclosures and public broadcast interviews.

When something goes wrong: two scenarios

The difference between backup-only recovery and a designed disaster recovery capability becomes visible the moment an incident occurs. This is what that difference looks like in practice:

Hour 0

Systems go down
Customer-facing services unavailable. Teams begin assessing what happened.
Line 1 | Braintree

Hours 4-24

Recovery planning begins
Teams identify the latest usable backup. Manual reconstruction planning starts. No clear timeline to restore.
Line 1 | Braintree
Line 1 | Braintree

Days 1-3

Partial data restored
Data restored to last snapshot. Configuration and application dependencies rebuilt manually. Data loss between last backup and incident.

Days 3-5+

Partial services restored
Customer impact continues. Revenue, trust, and productivity losses mount.
Line 1 | Braintree
Line 1 | Braintree

End state

Business resumes — but not as it was
Weeks of disruption. Unquantified data loss. Reputational damage already done.

Hour 0

Incident detected
Automated failover triggered. Recovery process initiates without manual intervention.

Line 1 | Braintree

Minutes 5–30

Services switch to secondary environment
Customer access maintained or briefly interrupted. Teams notified — not scrambling.

Line 1 | Braintree
Line 1 | Braintree

Hours 1–2

Systems fully operational
Minimal or no data loss. Root cause investigation begins without business pressure.

Same day

Normal operations continue
Recovery actions documented. Post-incident review scheduled.

Line 1 | Braintree
Line 1 | Braintree

End state

Business continued with minimal disruption
Downtime measured in minutes. Data loss negligible. Customers largely unaffected.

Recovery is a design outcome, not a backup policy

Reliable disaster recovery is built around two questions that need clear answers before an incident, not during one:
  • How quickly does the business need to resume operations? (Recovery Time Objective: RTO)
  • How much data loss can the business tolerate? (Recovery Point Objective: RPO)
These are technical questions, but they’re also business decisions. The acceptable level of downtime, the financial exposure of each additional hour, the regulatory consequences of extended unavailability: each threshold gets set at executive level and then translated into technical architecture by IT.
Effective BCDR also requires clear ownership across the organisation, not just within IT. Executive leadership defines the risk appetite. Risk and compliance translates that into policy. IT designs and operates the architecture to meet those requirements. Without that chain, no amount of technical tooling closes the gap.
azure backup section2 | Braintree

Azure Backup and Disaster Recovery, implemented properly

Braintree designs and operates disaster recovery solutions using Microsoft Azure Recovery Services. Depending on your environment and recovery requirements.

Azure Backup

Point-in-time protection for workloads, files, folders, and Azure virtual machines. Managed through Recovery Services Vaults, which handle retention policies, access control, and recovery point management.

Azure Site Recovery

Orchestrated failover and failback for Azure IaaS workloads. Enables Azure VMs to fail over to a secondary environment without manual reconfiguration: the capability that separates recovery in hours from recovery in minutes.

Azure Backup Server and MARS Agent

Protection for Windows Server environments and hybrid infrastructures, including on-premises workloads that form part of a mixed Azure and local environment.

Designed for real conditions, not ideal ones

Most recovery failures don’t happen because the backup technology failed. They happen because the recovery design assumed everything would go smoothly: the right people would be available, access credentials would work, dependencies would be clean, the runbook would be followed as written.
Braintree’s work on Azure environments is informed by what actually happens during incidents:
  • Degraded access conditions
  • Authentication failures under pressure
  • Application dependencies that weren’t documented
  • Recovery steps that work in isolation but not at scale.
We configure backup services, define recovery points, and test recovery paths with those conditions in mind.
As a Microsoft partner with direct access to Microsoft engineering, we can work through complex Azure Recovery Services configurations and edge cases without waiting in a support queue. For a production environment under active recovery, that access matters

Downtime is a risk you’re already carrying

Every organisation carries some level of exposure to disruption. It’s simply part of operating. The difference lies in how quickly you can get back to full speed when something goes wrong, and what that recovery costs you in lost productivity and trust.

 

A well-designed recovery capability turns what could be a crisis into a manageable event. That’s an outcome Braintree can help you plan for, today.

Talk to a Recovery Specialist

FAQs

Azure Backup focuses on protecting data by creating backup copies and recovery points. Disaster recovery is concerned with restoring full systems and services so the business can continue operating. In practice:
  • Backup allows you to restore files, folders, or workloads to a previous state
  • Disaster recovery allows you to resume applications, dependencies, and customer-facing services
Most recovery failures occur when organisations assume data protection automatically equals operational recovery.
Backup data is stored and managed within a Recovery Services Vault, which acts as the control plane for Azure Backup and related services. The vault is responsible for:
  • Managing recovery points and retention policies
  • Securing access to backup data through authorisation controls
  • Coordinating restores across Azure virtual machines, Windows Server workloads, and hybrid environments
Proper vault configuration is critical to ensuring backup data is usable during an incident.
Yes. Azure Backup supports a wide range of workloads, including Azure VMs and hybrid environments. Common use cases include:
  • Azure virtual machines running production workloads
  • Windows Server environments using Azure Backup Server
  • File- and folder-level protection via the Microsoft Azure Recovery Services (MARS) agent
Protection alone, however, does not guarantee recoverability at scale (which is why recovery testing matters).
Recovery should be tested regularly, and testing should go beyond restoring individual files or folders. Effective testing means:
  • Restoring entire Azure VMs or application stacks
  • Validating access, authentication, and directory dependencies
  • Measuring actual recovery time against defined objectives
Testing is the only way to confirm that recovery points, backup data, and processes work together under real conditions.

Azure Backup is generally cost effective, particularly when recovery requirements are clearly defined.

 

Costs are influenced by the number of protected instances (such as Azure VMs or servers) and the amounts of data retained in the Recovery Services Vault.

 

Without clear recovery objectives, costs can become unpredictable, either through over-retention or emergency recovery effort.

This is a common failure scenario. During incidents, teams may struggle with signing in, changing directories, or accessing recovery tooling. Effective recovery design accounts for:
  • Authorisation and role-based access during outages
  • Clear escalation paths when primary credentials are unavailable
  • Recovery procedures that do not depend on a single individual
Recovery plans should assume degraded access conditions, not ideal ones.
In most environments, yes. They serve different purposes.
  • Azure Backup protects data and supports point-in-time restores
  • Azure Site Recovery orchestrates failover and failback for Azure IaaS workloads
Using them together allows organisations to protect backup data while also enabling coordinated recovery of Azure virtual machines and services.

Recovery Time Objective (RTO) is how quickly the business needs to resume operations after an incident. Recovery Point Objective (RPO) is how much data loss the business can tolerate, defined by the gap between the last backup and the point of failure.


Both are business decisions, not technical ones. An RTO of four hours means four hours of acceptable operational disruption. An RPO of 24 hours means up to 24 hours of data could be lost. Most organisations have never formally defined these thresholds, which means their recovery architecture was designed to meet requirements nobody stated.

Stability and change have to coexist

Modernising on Azure does not require starting over. It requires understanding what already exists and designing for what comes next.
If you want to explore how Azure can support your organisation without destabilising the systems you rely on, we are happy to have that conversation.