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.
Table of Contents
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.).
Ways to minimize RPA
There are several ways to minimize Recovery Point Actual.
- 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 SpinOne that has an SLA of 99.9%, you will minimize the chances of a backup failure.
- 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.
- Schedule your backup so that it copies your data every day so that your RPA is minimal.
- 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 SpinOne cloud-to-cloud backup.