Recovery Point Objective (RPO) is the maximum tolerable data loss expressed in time (e.g. minutes, hours, days, weeks, etc.) that a business process can stand to lose before it is critically impacted. Establishing RPOs for the computer systems and applications used by each critical and non-critical business process is no easy undertaking. The RPO is traditionally established for each business process and their associated systems and applications during the Business Impact Analysis (BIA) study. Below are basic steps to developing your RPO:
Step 1. Determine Your Recovery Point Actual (RPA)
Before you start on the journey of RPOs, you need to determine what your Recovery Point Actual (RPA) is today for your critical systems and applications.
A frequent mistake when setting RPA for traditional daily tape offsite backups is to assume 24 hours for the RPO. This mistake is the result of not considering that the RPA time begins with the start of the first data backup used in the synchronization point, and must also include time for boxing the tapes, the inevitable contingency time that must be allowed for “waiting for courier transport”, and loading and final escape from site (not always at exactly the same time of day); the RPA must be increased by an amount of time equivalent to any such variability. It is also risky to assume that tapes will always be physically intact – the RPA should include enough time to use a previous synchronization point too.
You must know your RPA before you continue, so you know what the baseline is on potential data loss. Also, remember, if the data doesn’t go offsite, even through it’s backed up, your RPA is only as good as the last backup offsite.
Step 2. Determine Your Organizational RPO Needs
To help define what level of RPO categories your organization may need to consider, it is important to consider the following:
- Industry (e.g., financial, healthcare, retail, etc.) – Is your organization in an industry that simply cannot lose data due to its critical, complex nature and impact to its clients should it be lost?
- Legal / Regulatory Requirements – Is the organization under strict legal and regulatory guidelines regarding the protection and availability of data?
- Ability to Recreate – Is your organization a paperless environment or uses an automated workflow system that eliminates the use of paper records making recreation a nightmare?
- Volume – Can the business units easily recreate the data or is the sheer volume so significant that even a one-day’s loss is catastrophic?
- Downtime Procedures – Do you have effective downtime and/or manual workarounds to reduce RPO needs?
If I am a hospital or bank, we know our critical RPOs will be in minutes, hours or even zero data loss for key processes. Remember, you will need to establish various tiers of RPOs just like Recovery Time Objectives (RPOs). Even in a bank of hospital, not all business processes may have the same RPO for the systems and applications they use.
The lower RPOs you establish (e.g., minutes, hours, zero), the more complex and expensive the solution will be. But, the cost of data loss based on your industry, legal/regulatory requirements, ability to recreate and sheer volume could be catastrophic to your organization. Talk to several key business units to help you develop a reasonable set of RPO tiers that make sense for your business. Here is a sample RPO tier for a hospital:
|RPO 0 – 1 hour||Business processes and associated systems and applications can tolerate no more than 1 hour of data loss.|
|RPO 1 – 4 Hours||Business processes and associated systems and applications can tolerate up to 4 hours of data loss.|
|RPO 2 – 12 Hours||Business processes and associated systems and applications can tolerate up to 12 hours of data loss.|
|RPO 3 – 24 Hours||Business processes and associated systems and applications can tolerate up to one days data loss.|
|RPO 4 – > 24 Hours||Business processes and associated systems and applications can tolerate more than one day’s data loss.|
Remember, these are objectives; it may take you time to reach these timeframes. Also, a computer system and/or application may have different RPOs based on the business unit and their criticality. The lowest RPO set is the baseline for that computer system or application.
Step 3 – Determine Your RPOs
Now that you have the RPO tiers, you are ready to include it in your BIA questionnaire. For each business process identified, you must identify what the RPO should be. Go back to the criteria in Step 2 to help the business units determine what their RPO should be today. In some cases, it’s a no-brainer, in others there will need to be a discussion of needs versus wants.
As you can well expect, RPO timeframes are shortening due to today’s business needs. Gone are the days of tape backup and restore. However, surprisingly, we still have organizations backup up data nightly but leaving it onsite, organizations replicating data only locally and/or the business not knowing what is their RPA is based on what IT is doing with their data.