What is the Right Data Backup for My Business? Part 2: Questions To Ask

These days, choosing a backup solution can be as daunting as buying insurance. With so many options available, business owners often feel paralyzed when trying to navigate which backup options are right for their business. Like anything else, the lowest cost option is usually not the wisest choice. In this three part series we try and provide information to help business owners make the best choices when trying to answer the following question: What is the right data backup for my business?

Part 1 of this series we discussed: Backups vs. redundancy vs. replication

In Part 2 below, we’ll cover the questions that you and your IT Adviser should be reviewing while making a decision.

In Part 3, we’ll review which backup method may be right for your business.

Part 2. What questions to ask before evaluating backup types

What am I backing up?

First, you need to identify the systems and data that allow your business to function. List them in a spreadsheet. What are they? Where do they run? Are they on an in-house server, a virtual server in the cloud, or delivered as a service from a provider? Before you can develop a backup methodology, you need to understand everything that needs to be backed up.

Next, for each system and/or data location, you need to define your RTO and RPO.

What is my Recovery Time Objective (RTO)?

The Recovery Time Objective (RTO) is the duration of time and a service level within which a business process must be restored after a disaster in order to avoid unacceptable consequences associated with a break in continuity. In other words, the RTO is the answer to the question: “How much time did it take to recover after notification of business process disruption?“

The primary objective of performing backups is to be able to use the backup if and when necessary. Your backup system must be able to recover and restore data within a time duration that is acceptable to your business. A backup is of no use to your business if the restore duration is longer than is acceptable to the business. To illustrate this point, let’s take a look at the following example:

Background: ABC Orthopedics is a small medical practice with 20 computers and a server. The server performs the following functions. 1. PC and user authentication (allows PC’s to login). 2. data file storage. 3. hosts a practice management system, which stores all appointments, patient information, staff scheduling, etc. The server contains about 1TB of data and is backed up by the firms’ IT provider.
Scenario: One day, the server is flashing red and orange lights. It won’t power on. PC’s cannot login. The practice’s management system is down. Staff cannot confirm appointments, Doctors cannot access patient information. The IT provider is notified and confirms the problem. Good thing the server was being backed up right? Not so fast…
The IT provider is utilizing a cloud backup service (such as CrashPlan) for the server data. The data is stored in the cloud. It must be downloaded and restored to a working server before it’s usable. Even with the practice’s fast internet connection, the IT provider estimates that it will take 72+ hours to download the backup. Further, a new server must be procured, delivered and setup before the backup can be restored. Five days later, a new server is setup, the data is restored and the practice is up and running again with minimal data loss. Victory? Nope.
Outcome: The practice has been offline for 1 week. We can all imagine a litany of problems, financial, legal and ethical that result from the ABC Orthopedics not being able to service and bill its patients for 5 days.

What went wrong? A RTO (Recovery Time Objective) was never discussed or defined. In hindsight, the business owners actual RTO is 24 hours. The backup system that was implemented, while inexpensive, was not effective as it left the practice unable to operate for 5 days.

What is my Recovery Point Objective (RPO)?

Recovery Point Objective (RPO) describes the interval of time that might pass during a disruption before the quantity of data lost during that period exceeds the businesses maximum allowable threshold or tolerance. Simply put, RPO is the amount of time that is acceptable for data loss. If a business defines its RPO as 12 hours, then it is saying it is willing to re-enter or re-create data that was added or modified in the system within the past 12 hours.

In the above example, ABC Orthopedics’ IT Provider was likely scheduling the backup to run once per day (let’s say at 11:00PM every night) and the backup takes 1 hour to run. To further the scenario, let’s say the server crash happened at 4:00PM and the backup from the previous night was successful. ABC Orthpedic’s hours are 9AM to 5PM. With these variables, we calculate that the amount of data time lost is 7 hours. A good backup completed at 12AM, and data was modified from 9AM to 4PM (when the server crashed).

So, not only was ABC Orthopedics out of business for 5 days, but once their IT provider got everything restored, they lost 7 hours worth of data. Details on patients and their appointments for the day of crash are lost. Hopefully ABC Orthopedics has either: paper records of the appointment details; or a staff with very good memories. All of this data will need to be reentered into the system.

One last note when thinking about RPO. By definition, RPO must be less than the RTO.

Next steps?

With these questions answered, you’re ready to start developing a backup system. Stay tuned for Part 3 of this series where we will review various backup methods.