Skip to main content
Druva Documentation

Managing Recovery Point Actual

Phoenix Editions: File:/cross.pngBusiness         File:/tick.png Enterprise     File:/tick.pngElite
(Purchase Separately)

Overview

Recovery Point Actual (RPA) represents the time elapsed since the last successful snapshot 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 snapshot

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 snapshot 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 snapshot 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 snapshot 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.Snapshot)) >= (Current_time - R.Snapshot))

Factors that determine RPA

Factor Description
Current time Time when you are on the DR Plan > Virtual Machines list view.

B.snapshot 

The timestamp of virtual machine snapshot taken at the time of backup of the recovery point.
R.snapshot B.snapshot 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 snapshot 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 and 8th Jan 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.snapshot) = (1.25 * 24hrs) = 30 hours

 is lesser than

(Current_time - R.Snapshot) = 54 hours 

Not a recommended RPA.

After today’s backup job is finished and 9th Jan 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.snapshot) = (1.25 * 24hrs) = 30 hours

Equals to

(Current_time - R.Snapshot)  = 30 hours

Meets the recommendation. 

  • Was this article helpful?