Azure Site Recovery aka ASR is well known for Disaster recovery and Migration, well here we will be discussing 2 terms which decide your DR strategy so here we will be talking about only RPO and RTO. We all have heard these terms in respect to DR set-up. Lest see what it means :
Recovery Point Objective (RPO)
In plain English it simply means , how much data customer can afford or willing to loose during DR situation or you can understand this by the frequency you are backing up your data for .e.g. if you run your backup twice at 10 am and 10 pm and disaster hits at 4PM then your RPO is 6 hours.
So we have seen RPO is usally depend upon backup policies if someone sets up a backup policy daily then RPO is closer to a day.
Recovery Time Objective (RTO)
This simply means when DR happens then how long would it take to get up and running from the time Disaster hit us.
Well its not actually possible to define actual RPO and RTO because there are several variables involved but still it is critical to understand and plan.
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.
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.
Recovery Point Objective (RPO)
In plain English it simply means , how much data customer can afford or willing to loose during DR situation or you can understand this by the frequency you are backing up your data for .e.g. if you run your backup twice at 10 am and 10 pm and disaster hits at 4PM then your RPO is 6 hours.
So we have seen RPO is usally depend upon backup policies if someone sets up a backup policy daily then RPO is closer to a day.
Recovery Time Objective (RTO)
This simply means when DR happens then how long would it take to get up and running from the time Disaster hit us.
Well its not actually possible to define actual RPO and RTO because there are several variables involved but still it is critical to understand and plan.
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.
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.
No comments:
Post a Comment