As someone who has worked in IT departments and an IT consultant for a Managed Service Provider (MSP), Business Continuity plans are something I’ve been involved in quite a lot. 

Either recovering from a threat or designing a solution that could recover from a threat.

Business Continuity is the process of creating systems of prevention and recovery to deal with any potential threats to your company.  Those threats could be a natural threat, such as fire or flood or something such as an accidental misconfiguration of a system or a malicious attack from an outside source.

Whatever the threat, Business Continuity can be implemented in the form of backup and or disaster recovery.  When looking at Disaster Recovery and planning for that horror scenario within your environment you need to understand what you are planning on protecting, what would actually trigger your disaster recovery plan into action.  

What is RPO and RTO in azure ASR ?

Two parts of a disaster recovery plan:

Recovery point objective (RPO): The amount of acceptable data loss if a recovery needs to be done.

For Azure backup solutions have wide variability in their acceptable RPO. Virtual machine backups usually have an RPO of one day, while database backups have RPOs as low as 15 minutes.

For Azure Site Recovery solutions have low RPOs. The DR copy can be behind by a few seconds or a few minutes

·         For each Protected Instance configured for On-Premises-to-Azure planned and unplanned Failover, we guarantee a two-hour Recovery Time Objective.

·         For each Protected Instance configured for Azure-to-Azure Failover, we guarantee a two-hour Recovery Time Objective.

Recovery Time Objective and Service Levels for Azure-to-Azure Failover

“Recovery Time Objective (RTO)” means the period of time beginning when Customer initiates a Failover of a Protected Instance for Azure-to-Azure replication to the time when the Protected Instance is running as a virtual machine in secondary Azure region, excluding any time associated with manual action or the execution of Customer scripts.

“Monthly Recovery Time Objective” for a specific Protected Instance configured for Azure-to-Azure replication in a given billing month is 2 hours.

Recovery Time Objective and Service Levels for On-Premises-to-Azure Failover

“Recovery Time Objective (RTO)” means the period of time beginning when Customer initiates a Failover of a Protected Instance experiencing either a planned or unplanned outage for On-Premises-to-Azure replication to the time when the Protected Instance is running as a virtual machine in Microsoft Azure, excluding any time associated with manual action or the execution of Customer scripts.

“Monthly Recovery Time Objective” for a specific Protected Instance configured for On-Premises-to-Azure replication in a given billing month is 2 hours.

• More traditional IaaS Azure business continuance and disaster recovery solutions like Azure backup and Azure Site Recovery (ASR), as well as many of our Azure Marketplace partner protection solutions, are generally asynchronous by design and therefore provide RPOs > 0.
• From a design perspective it is nearly impossible to guarantee specific RPOs and RTOs for these types of solutions because many variables are outside of your control, HOWEVER, here are some general guidelines…
• RPO of backup solutions are most dependent on the backup policies.  For example, if someone setups up a daily backup policy, then the RPO is closer to a day. 
• RPO of replication solutions are often most dependent on the distance separating the two sites.  For example, when someone configures ASR to replicate across two regions, then the RPO is more likely to be in the ~seconds to many seconds range.
• When designing for RTO it is important to understand the variables that are not always in your control.  For example, if someone initiates a restore, the time it takes to be back up and running is dependent on variables like the size of the restore, available network bandwidth, speed of the disk drives/VMs, etc.
• In a more traditional DR failover scenario whether onprem to cloud or cloud to cloud, it is common to use a service like Azure Site Recovery.  Since the data has already been replicated, the RTO in this case has many dependencies including how long it takes to provision the DR infrastructure on the ‘other side’, speed of the disk drives/VMs, time to run the recovery plan, time to propagate the appropriate DNS changes to point to the ‘other’ side, etc.  Generally in the ~minutes to many minutes range.

AZURE BACKUP

At its core, it’s a Backup-As-A-Service (BaaS) solution. That means it provides your business with the tools you need to back up all of your vital data, with customization options specific to your situation.

Azure Backup can protect anything from your SharePoint, Exchange and SQL servers to your local files and folders, and any part of your Azure solution. The data is stored remotely and is available anytime you need to access it or restore your systems and servers.

What can I back up?

• On-premises – Back up files, folders, system state using the Microsoft Azure Recovery Services (MARS) agent. Or use the DPM or Azure Backup Server (MABS) agent to protect on-premises VMs (Hyper-V and VMWare) and other on-premises workloads
• Azure VMs – Back up entire Windows/Linux VMs (using backup extensions) or back up files, folders, and system state using the MARS agent.
• Azure Files shares – Back up Azure File shares to a storage account
• SQL Server in Azure VMs – Back up SQL Server databases running on Azure VMs
• SAP HANA databases in Azure VMs – Backup SAP HANA databases running on Azure VMs

Reasons Azure Backup is an Affordable Option for Cloud Backup:

1.Flexible Pricing: Your cost will not be based on a flat rate as would be the case for most hybrid or on-premise storage and backup solutions. Instead, it follows a pay-as-used model in which your rate will depend on the amount of data stored at a given billing time.

This page breaks down the pricing structure of Azure Backup in more detail.

2. Scalability: It’s full power as a cloud backup solution. Because you are not reliant on internal servers for your storage, data can expand exponentially without any storage expansion necessary.

3. Data Security: Any successful cloud storage solution has to ensure that all data is sufficiently protected. Fortunately, Azure Backup has built a number of security measures into its solution that ensures this will always be the case.

4. Backup Variations: Microsoft offers three distinct ways to backup your data.

• MARS
• DPM
• MABS

Perhaps Unlimited Data Transfer & Restore Flexibility.

Reference: https://azure.microsoft.com/en-in/services/backup/

For any consulting requirements, please email us on cloud@proarch.com