Skip to content
English
Customer ticket portal
  • There are no suggestions because the search field is empty.

Recovery Point Objective

What is a Recovery Point Objective?

A recovery point objective (RPO) is an industry standard term representing the maximum acceptable age of data that can be recovered in the event of a disaster. It represents the “freshness” of data in the recovery environment.

For each application in Arpio, you can define a recovery point objective in minutes or hours, and Arpio works to ensure your latest recovery point is never older than this objective. You can also configure real-time RPO replication for supported resource types.

How Arpio achieves your RPO

Arpio uses predictive analytics to achieve your recovery point objective by predicting how long it will take to capture the next recovery point. If your recovery point objective is 60 minutes, and Arpio believes it will take 12 minutes to create the next recovery point, Arpio will begin that process when the current recovery point is 48 minutes old.

The ability to achieve a given recovery point objective depends on the cloud services being used and how long it takes the cloud provider to capture each service’s state and replicate it to the recovery environment. Factors such as data volume, resource count, and cloud provider rate limits all influence backup duration.

RPO settings

You configure the RPO for each application when creating an application, and you can adjust it at any time in your application settings. Arpio supports snapshot-based RPO replication from every 15 minutes up to 24 hours.

AWS RPO considerations

On AWS, Arpio supports both snapshot-based and real-time RPO replication. When real-time replication is enabled, supported resources achieve an RPO of seconds rather than minutes or hours.

Supported resource types for real-time replication on AWS include:

To enable real-time replication, adjust the RPO slider in your application settings to the furthest left position. See real-time RPO replication for details.

For snapshot-based replication on AWS, the achievable RPO depends on factors such as the size of your EBS volumes and databases, the number of concurrent snapshot copies (AWS imposes a default limit of 20 concurrent cross-region snapshot copies), and the time AWS services take to complete backup operations.

Azure RPO considerations

On Azure, Arpio currently supports snapshot-based RPO replication. Arpio uses native Azure capabilities including VM Restore Points, managed disk snapshots, and blob storage object replication to capture your resources on each backup cycle. Azure uses Real-Time Replication for the following resources by default:

  • Storage Accounts
  • Blob Containers
  • Azure SQL Databases

There are some Azure-specific factors that influence achievable RPO:

  • VM Restore Point rate limits: Azure limits the creation of VM Restore Points to 1 snapshot every 20 minutes per virtual machine. This means that for applications with virtual machines, the practical minimum RPO is approximately 40 minutes. Setting a more aggressive RPO (such as 15 minutes) may result in occasional backup delays while Arpio retries rate-limited operations.
  • Disk size and cross-region copy time: Initial backups for large disks can take many hours to complete. After the initial backup, incremental disk snapshots are significantly faster. The time for cross-region disk restore point copies depends on disk size and Azure’s current throughput in the source and target regions.
  • VM Agent health: Application-consistent VM Restore Points require a healthy Azure VM Agent on each virtual machine. If the VM Agent is unresponsive, Arpio will fall back to crash-consistent restore points, which do not require guest OS coordination.

Monitoring your RPO

Arpio provides an RPO graph on each application page that shows the age of your most recent recovery point over time. This graph helps you identify whether your application is consistently meeting its RPO target or if there are resources that regularly exceed the configured objective.

If your application consistently exceeds its RPO, common steps to improve backup performance include:

  • Identifying which resources have the longest backup duration and evaluating whether they can be split into a separate application with a less strict RPO.
  • On AWS: enabling real-time replication for large databases to eliminate snapshot-based backup delays ;checking for concurrent snapshot copy quota limits and requesting increases if needed.
  • On Azure: ensuring VM Agents are healthy on all virtual machines and verifying that disk sizes and churn rates are compatible with the desired RPO.

If you need help diagnosing RPO issues, contact Arpio support for assistance.