How to
site recovery works
The Main Components of ASR
The Main Components of ASR
business continuity and disaster
recovery (BC/DR)
Business continuity and disaster recovery
(BCDR or BC/DR) is a set of processes and techniques used to help an
organization recover from a disaster and continue or resume routine business
operations. It is a broad term that combines the roles and functions of IT and
business in the aftermath of a disaster.
- Business Continuity (BC): BC deals with the business operations side of BCDR. It involves designing and creating policies and procedures that ensure that essential business functions/processes are available during and after a disaster. BC can include the replacement of staff, service availability issues, business impact analysis and change management.
2. Disaster Recovery (DR):
DR is primarily focused on the IT side of BCDR. It defines how an
organization’s IT department will recover from a natural or effective disaster.
The processes within this phase can include server and network restoration,
copying backup data and provisioning backup systems.
Continuous Replication
There could be any workload VMware,
Hyper-V, Physical server, if you do any changes in server there will replicated
mediately,
When you set up replications the
replication is continuous meanings as you make changes those updates are being
replicated into azure storage and you can eventually bring the servers online
in another site
Application-Consistent Snapshots
when enable replications for system you can
replicate using recovery points with these applications consistent snapshots, So
the snapshot are capturing disk data, but it’s also grabbing what’s in memory
and any transactions that are in process, so as you failover you can make that
you’ve got the most consistent version the applications captured in that replicated
snapshot, and you can bring that online if you’re failing over. Now in
`
Flexible failover
In terms of failover you’ve got some flexibility. You can run planned
failovers for expected outage with 0 data loss. SO
This is great in those scenarios where you’ve testing things out your
disaster recovery solution, and then there’ also support for unplanned
failovers and those true disaster scenarios, and that gives you minimal data
loss, depending on the replications frequency and how you have things set up,
one of the key components is being able to failback from that secondary site
back to your original primary site, and there’s support for that as well
Recovery plan
Consider the scenario where you’ve got multiple
server all powering a single workload and you want to those to be replicated
and failed over together as a group. The recovery plans feature allows you to
do that, and the
Azure Automation integration
The Automation account can be in any Azure
region, and must be in the same subscription as the Site Recovery vault.
A runbook can run in a recovery plan during
failover from a primary location to secondary, or during failback from the
secondary location to the primary.
Runbooks in a recovery plan run serially,
one after another, in the set order.
If runbooks in a recovery plan configure
VMs to start in different groups, the recovery plan will continue only when
Azure reports all VMs as running.
Recovery plans continue to run, even if a
script fails.
