Site Recovery in Replication Policy
AZ-304 is retired. AZ-305 replacement is available.
In this tutorial we will learn about the Replication policy and the various recovery point. Moreover, we will understand about the Site Recovery process.
Replication policy
Replication policy explains the settings for the retention history of recovery points. Moreover, it also defines the frequency of app-consistent snapshots and by default, Azure Site Recovery creates a new replication policy with default settings of:
- Firstly, 4 hours for the retention history of recovery points.
- Secondly, 4 hours for the frequency of app-consistent snapshots.
Types of Recovery Point
Crash-consistent recovery point
Crash-consistent recovery point contains on-disk data as if you want to pull the power cord from the server during the snapshot. However, it will not include anything in memory at the time when the snapshot was taken. You should know that today, most applications can recover well from crash-consistent snapshots. The crash-consistent recovery point is usually enough for no-database operating systems and applications like file servers, DHCP servers, and print servers.
For frequency of crash-consistent recovery point generation, Site Recovery creates a crash-consistent recovery point every 5 minutes.
Application-consistent recovery point
Application-consistent recovery points development is from application-consistent snapshots. They are responsible for capturing the same data as crash-consistent snapshots while also capturing data in memory and all transactions in process. However, they have extra content, in which the application-consistent snapshots are the most involved and take the longest. Also, it is recommended to have application-consistent recovery points for database operating systems and applications like SQL Server.
Impact of application-consistent recovery points on application performance
Application-consistent recovery points are responsible for capturing all the data in memory and with-in process. However, they require frameworks such as Volume Shadow Copy Service on Windows to quiesce the application. And, if the capturing process is frequent, then it can affect performance when the workload is already busy. And, it is not recommended to use low frequency for app-consistent recovery points for non-database workloads. Even for database workload, 1 hour is enough. However, site recovery can develop an application-consistent recovery point with a minimum frequency of 1 hour.
Process of generating Recovery points
For understanding how Site Recovery generates recovery points, let’s take an example of a replication policy. However, this replication policy has a recovery point with a 24-hour retention window and an app-consistent frequency snapshot of 1 hour.
Site Recovery develops a crash-consistent recovery point every 5 minutes, in which you can’t change this frequency. And, for the last hour, you can choose from 12 crash-consistent points and 1 app-consistent point. However, as time progresses, Site Recovery prunes all the recovery points beyond the last hour and saves only 1 recovery point per hour. You should know that the oldest recovery point that you can use is 72 hours.
Reference: Microsoft Documentation