Welcome to Part 2 of our 3-Part blog series by one of the hands-on experts in the data protection field and guest blogger, Eugene Alfaro. In Part 1 we shared challenges and tips based on a true story about data loss. In Part 2 you will find useful tactics for your data protection strategy with a particular focus on RTO and RPO definitions. For even more tips be sure to check out our latest data protection best practice White Paper.
Tactic #1 - When explaining RTO and RPO, always share the impact on cost
There is nothing that gets the attention of executives and upper management than sharing a dollar figure. Whether it is the impact on revenue or expenses, the good 'ol Benjamin is better than caffeine in the morning. As you define and explain the meaning of RPO and RTOs, associate costs. Here's what I've used often when consulting senior management:
"As we define our company's RTOs and RPOs, keep in mind that the lower the number the higher the cost. The cost of our DR solution will be relative to the RTOs and RPOs we define in this meeting."
If you are proposing solutions, show the extreme to share the impact on cost. In other words, come with a low-cost solution (eg. backup-to-tape with offsite shipments) and explain how it delivers high RPO and RTO times. Then, show them the highest cost solution (e.g. full replication of data to remote DR facility with compute on standby) that delivers extremely low RPO and RTO times. They will likely ask for something in between but now they should get the point that demanding high-availability and low RPO and RTO times is entirely dependent on the funds they approve for the project.
A common mistake is to assume that the time to restore data is the same as the time to backup that same data. Unfortunately, that has never been the case in our field experiences and highly improbable simply due to the way in which data transfer is handled. This is true of any of the common technologies we use. Hard drives, optical media, and flash memory all output data faster than they accept input. Hence, writing data will always be slower than reading it.
There are practical, although arguable, methods to estimate your recovery times. One simple method is to employ a 2.5x factor to your backup times. If your ERP environment backup completes in 4 hours, expect it to take 10 hours to restore. This is just the time from the moment you begin the recovery to the moment it's completed. It does not include the human activities to find the backup source, prepare the environment to restore to, verify the data after recovery, and restore service to the end users. Those activities are entirely dependent on people resources you have available to you.
Tactic #3 - With backup and recovery technologies, one size does not fit all
No single technology is best for all scenarios. Unfortunately, a DR strategy has to take into account many different scenarios. With regard to RTO and RPO times, there will be some applications that require real-time recovery such as ERP and CRM systems. Some may need fast recovery but not real-time such as email systems and websites. While others are fine with longer downtime such as archive files and user personal files. Therefore, consider implementing different solutions that address the various scenarios.
As an example, in our DR solutions we employ near real-time replication for ERP applications, local backup-to-disk with remote replication for other business critical systems, and backup to near-line or cloud systems for non-critical data. No single backup technology provides all of those options well. Choose multiple systems (preferably from a single vendor) to address your various needs.
Tactic #4 - Raise awareness of your capabilities
No one wants to air dirty laundry. However, when it comes to DR, knowing what you cannot do may help get the funding support to make improvements. Does anyone know that you estimate a recovery time of 24 hours for your ERP system? If the manager of the Accounts Receivable department who is responsible for collecting cash from customers knew that, they'll likely help raise more than eyebrows around the office. Does the head of shipping and receiving know that they would have to manually create shipping labels for 2 days if the warehouse application were to go down? At the end of a quarter, that could mean making or breaking your quarterly revenue objectives. For a public company that answers to Wall Street, that could mean millions - if not billions - in market value gone in a single trading hour.
These are practical tactics we've employed successfully in the field when consulting our customers regarding their ongoing battle with getting the business to help define RTO and RPO times and fund the solutions accordingly.
About our guest blogger: Eugene Alfaro leads IT engineering for Cornerstone Technologies, an IT engineering services firm in San Jose, Calif. He has also architected, managed and operated corporate IT environments for multinational companies. He has been a speaker on topics such as virtualization, private/public cloud services, WAN optimization, enterprise storage and VoIP, among others.