Home » Spin.AI Blog » SaaS Backup and Recovery » Recovery Point Actual: a Critical Indicator for SMB Disaster Recovery
May 20, 2023 | Updated on: April 11, 2024 | Reading time 8 minutes

Recovery Point Actual: a Critical Indicator for SMB Disaster Recovery

Many small and even medium businesses do not have a well-articulated disaster recovery strategy for their IT systems. This approach can cost them a substantial amount of money and even can cause business termination. In this article, we discuss the Recovery Point Actual, one of the critical indicators of disaster recovery.

What is Recovery Point Actual

Recovery Point Actual is a complex indicator to grasp, but we’ll try to make it easy for you.

Imagine a situation where a company’s data has been wiped in a major incident. Its IT team wants to get data out of the backup. The last backup they made was 2 weeks ago.

In this case, their recovery point actual will be the two-week-old data. All the data that has been generated during the last two weeks will be beyond recovery and lost forever.

Let’s take a look at another situation. Another company’s data was deleted in a similar incident. However, they made the last backup the day before the incident. It means that their recovery point actual is one day.

Similarly, a company that made no data backup will have no RPA as their data will not be restored.

Summing up, Recovery Point Actual measures the age of recovered data. The younger it is, the better.

What’s the difference between RPA, RPO, RTA, and RTO

Other important indicators of Disaster Recovery Strategy are RPO, RTA, and RTO. Let’s quickly overview each of them.

Recovery Point Objective (RPO) is similar to RPA. Think of it as your company’s restoration goal. RPO identifies the desired limits for the outdatedness of recovered data.

For example, a company wants to be able to recover data that was generated on the day preceding the incident. They are not ready to lose more than 24 hours’ worth of data. Their  RPO is thus one day.

Recovery Time Objective defines how much time the company wants to spend recovering from the data incident. Recovery Time Actual (RTA) is how much time the company has actually spent recovering data.

RPA and Disaster Recovery Strategy

The difference between Recovery Point Objective and Recovery Point Actual is critical in assessing the recovery capabilities of a business. Ultimately, it impacts your disaster recovery strategy and data loss prevention activities.

The goal of your business is to make RPA equal to or smaller than RPO. It is hard to actually find out what your RPA would be unless you have a major data loss event.

What can help is assessing the frequency of your backup as well as the accuracy of your recovery (e.g., how many data entries have been lost, etc.).

Control Recovery Point Actual with SpinBackup
In Spinbackup you can control the frequency of backups to control RPA

Ways to minimize RPA

There are several ways to minimize Recovery Point Actual.

  1. Get an automated backup for your critical data. This way, you will be able to exclude human factors from your backup activities. Tools do not forget to carry out their functions. And if you get a solution like Spinbackup that has an SLA of 99.9%, you will minimize the chances of a backup failure.
  2. Follow the 3-2-1 rule. Having 3 copies of data on two different data carriers, one located offsite, will increase your chances of data recovery.
  3. Schedule your backup so that it copies your data every day so that your RPA is minimal.
  4. When choosing cloud data backup, look for tools that enable you to download data on a local device. Cloud recovery is much longer than on-prem recovery due to the use of API calls.
    If you have a cloud-to-cloud backup for your Google Workspace or Microsoft 365, you can download the data to your desktop. Once downloaded, ask your employees to work with on-prem tools. This can be done during the recovery process. It will minimize your downtime.

Learn about SpinBackup cloud-to-cloud backup.

Was this helpful?

Thanks for your feedback!
Avatar photo

VP of Engineering

About Author

Sergiy Balynsky is the VP of Engineering at Spin.AI, responsible for guiding the company's technological vision and overseeing engineering teams.

He played a key role in launching a modern, scalable platform that has become the market leader, serving millions of users.

Before joining Spin.AI, Sergiy contributed to AI/ML projects, fintech startups, and banking domains, where he successfully managed teams of over 100 engineers and analysts. With 15 years of experience in building world-class engineering teams and developing innovative cloud products, Sergiy holds a Master's degree in Computer Science.

His primary focus lies in team management, cybersecurity, AI/ML, and the development and scaling of innovative cloud products.

How Can You Maximize SaaS Security Benefits?

Let's get started with a live demo

Latest blog posts

Protecting Partner Margins: An Inside Look at the New Spin.AI Partn...

Google recently announced a 40% reduction in the partner margin for Google Workspace renewals –... Read more

saas application data protection fundamentals

Expert Insights: SaaS Application Data Protection Fundamentals

SaaS applications appeal to organizations because they make running the application “somebody else’s problem.” However,... Read more