MICROSOFT PRODUCT CAPABILITIES
Make recovery a working process.
Azure Backup and Azure Site Recovery serve different purposes. Backup keeps recovery points for supported workloads. Site Recovery replicates supported systems and orchestrates failover when the normal environment cannot run them.
Azure Backup
Apply backup policies and retention to supported virtual machines, files, and databases, with recovery points managed through Azure vaults.
Recovery protection
Use supported features such as soft delete, immutability, and protected administrative operations as part of the backup design.
Azure Site Recovery
Replicate supported Azure and on-premises machines and organise their failover into recovery plans.
Recovery testing
Test restores and failover, including application dependencies, network access, user connectivity, and the sequence needed to resume work.
Set the recovery objective first
Agree recovery point and recovery time objectives for each workload. Replication, retained backups, and application-aware testing address different failure scenarios and have different storage and compute costs.
Put it to work with Braintree.
Braintree designs the protection policies and recovery plans, configures the services, and tests the process with your team so technical recovery supports the business’s priorities.
Microsoft product guidance
Define the recovery you need
Recovery time and acceptable data loss are business decisions before they become technical settings. Braintree can translate those decisions into a design, documented responsibilities and a programme of recovery validation.
✓
Agree recovery time and recovery point objectives by workload.
✓
Map identity, networking and application dependencies.
✓
Plan access and escalation when normal credentials or systems are unavailable.
✓
Test the runbook and retain evidence of the results.
01
Define what must work after an incident
A backup discussion begins with the information to protect. A recovery discussion also asks which applications, identities, connections and people are needed to resume the business process. A usable copy of a database does not by itself restore the customer portal, the authentication service or the integration that depends on it.
An illustrative recovery test for a three-tier application should examine the database, application layer and customer-facing service together. The team needs to confirm access, network routes and the order in which components become available. The test succeeds when the business transaction works, not merely when a virtual machine starts.
02
Backup and replication solve related but different problems
Azure Backup provides recovery points and retention for supported workloads. Azure Site Recovery manages replication, failover and failback for supported scenarios. The choice depends on whether the requirement is to restore data from a previous point, restart a workload in another location or both.
A recovery design should also consider the event being addressed. Accidental deletion, application corruption, an infrastructure outage and a security incident can require different recovery choices. Replicating a change is not always the same as preserving a clean historical copy. The design needs to state which recovery points or alternative environments are suitable for each scenario.
03
RTO and RPO must be attached to a workload
Recovery Time Objective describes the intended time to restore the service. Recovery Point Objective describes the acceptable loss of recent data. These are planning targets agreed with the business; they are not universal product guarantees. Different applications can need different targets and budgets.
Microsoft recovery plans allow applications to be grouped around dependencies, with ordered startup, automation and manual actions. A runbook therefore needs both technical steps and decision ownership. If the normal administrator cannot sign in, the recovery process needs an authorised alternative. If the customer-facing service requires a DNS or firewall change, that responsibility must appear in the plan.
04
Test the whole recovery path
Braintree’s published recovery scope includes defining objectives, configuring protection and testing access and application dependencies. The proposal should identify the workloads, protection services, test environment and ongoing review responsibilities. Test results should be retained as evidence of what actually worked.
Agree workload-specific recovery objectives and acceptable interruption.
Map identity, network, application and third-party dependencies.
Configure retention, access controls and the appropriate recovery services.
Run representative restores or test failovers and record observed results.
Update runbooks after application changes and assign ownership for retesting.
BEFORE YOU DECIDE
