Enterprise Workloads Editions
❌ Business| ✅ Enterprise (Purchase Separately) | ✅ Elite
Overview
Recovery Point Actual (RPA) represents the time elapsed since the last successful recovery point of the VM that is available for failover. Recovery Point Actual (RPA) also helps you to derive the amount of data you might lose when you perform a failover at the time of disaster recovery.
RPA helps you to meet your RPO requirements and adhering to business requirements.
How is RPA is calculated
RPA = Current time - Time of VMware recovery point
The RPA time is updated only after the DR restore job completes successfully for the recovery point created for the virtual machine.
The following diagram illustrates the concept of RPA.
Time | Activity |
8.00 PM, on August 24th | Backup starts ( 8 GB data).
Backup frequency is set to daily. |
8.15 PM on August 24th | The recovery point is taken. |
10.00 PM on August 24th | The DR job is triggered immediately after backup.
Till here the RPA for the VM is Null as the DR restore is not completed yet. |
1.00 AM on August 25th | DR restore completes. |
1.00 AM on August 25th | RPA is updated at 1.00 AM on August 25th
RPA value = 5 hours since recovery point time is 8.15 PM on August 24th |
8.00 AM on August 25th | Disaster is recorded.
Total data on VM is 9 GB. |
8.00 AM on August 25th | RPA value = 12 hours since recovery point time is 8.15 PM on August 24th
Total data loss = 1 GB. |
Managing RPA
The RPA should not exceed the backup frequency duration. For example, If the backup is scheduled to be run daily then the RPA must not be more than 24 hours.
RPA values that are potential risks are displayed in red.
You can use the following formula to manage your RPA:
(1.25 * (Next_schedule - B.Recovery point)) >= (Current_time - R.Recovery point))
Factor | Description |
Current time | Time when you are on the DR Plan > Virtual Machines list view. |
B.recovery point | The timestamp of virtual machine recovery point taken at the time of backup of the recovery point. |
R.recovery point | B.recovery point only after the recovery point is successfully DR restored. |
Next Schedule | Start time of planned next schedule of backup for given virtual machine.
OR
If the backup job is currently running, it’s backup job start time. |
Multiplier (1.25) | This is a factor and not the extension of the time window because in-frequent backups see more data change requiring longer backup and DR restore job lifetime. |
Examples
The following examples will help you better understand the logic of managing your RPA.
Scenario
Backup window start - each day at 5.00 AM
Backup recovery point time : 5.00 AM
Let's say today is 10 Jan 2020, 11 AM
8th Jan - RP (Recovery Point) 1 - DR restored RP
9th Jan - RP2
10th Jan - RP3 ← Latest RP
11th Jan - Current
After today’s backup job is finished and8thJan RP is DR restored:
RPA value will be:
1.25 *(11/JAN/2020:5AM - 10/JAN/2020:5AM)) >= ( 10/JAN/2020:11 AM - 08/JAN/2020:5AM)
1.25 * (Next_schedule - B.recovery point) = (1.25 * 24hrs) = 30 hours
is lesser than
(Current_time - R.recovery point) = 54 hours
Not a recommended RPA.
After today’s backup job is finished and9thJan RP is DR restored
RPA value will be:
(1.25 *(11/JAN/2020:5AM - 10/JAN/2020:5AM)) >= ( 10/JAN/2020:11 AM - 09/JAN/2020:5AM)
1.25 * (Next_schedule - B.recovery point) = (1.25 * 24hrs) = 30 hours
Equals to
(Current_time - R.recovery point) = 30 hours
Meets the recommendation.