Skip to main content
Managing Recovery Point Actual
Updated over a week ago

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.

RPA_concept.png

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.

Did this answer your question?