Top 10 Things You Want in Your Backup Contract (Part 6)
When it comes to disaster recovery, service providers should put guarantees around the items they have control of and properly define those they do not to avoid confusion and wrong expectations.
December 10, 2012
By Zenith Infotech 1
This installment, “Recovering from a Disaster,” seems like something that should not be in your contract; however, you could be setting the wrong expectations if you don’t address it.
Disclaimer: Take these as basic starting templates and get local legal advice, as local jurisdictions may require specific changes.
Now for the “normal” disaster. Your customer has called and indicated that their building just burned to the ground, and they want you to recover their systems. What expectations did you set? Is it defined as best effort? Did you put clauses in your contract that are based upon someone else’s performance? There are a couple of rules you need to establish for any “disaster” that can happen to your customer where you are required to bring back their systems into an operational state:
Define who can call a disaster. You don’t want just anyone calling you up and declaring the disaster, and then you mobilize all of your resources only to find out that it is false.
Define the Recovery Time Objective (RTO), Recovery Point Objective (RPO) and the Recovery Service Level (RSL) for each and every server that you are responsible for restoring. This must be done up front with the customer, as it sets not only these critical factors, but also helps you determine if the solution you are providing meets with the customer’s expectations.
Define who is providing the replacement technology, how it is delivered and if it must be EXACT or not. Remember, the last thing you want to worry about is restoring to different hardware during a critical time. Make sure that you define that your restore process starts ONCE the replacement hardware has been delivered. This can cause a serious impact if the replacement hardware is ordered with a two-week delivery, and your customer was expecting a couple of days!
Define the emergency location for complete site disasters ahead of time. This is not always possible; however, you can add that your response time will be defined as once the replacement site is available for the restore.
If you are providing emergency server virtualization as part of your “business continuity” contract, make sure that you can meet the RTO, RPO and RSL as you have them defined.
Make sure to cover the logistics of transfer time. This means define a very safe restore time based upon XX minutes per Gigabyte of data, or leave it completely open depending on the amount of data your customer has. You can cover how fast you START the restore once the replacement hardware is available, but don’t lock yourself into an exact time.
Define the hours you will work and any special charges that might be applied during a “declared” disaster.
Bottom Line: Put guarantees around the items YOU have control of and properly define those you do not. Next time, we will talk about what you are backing up.
If you are interested in finding more about Zenith’s TigerCloud with built-in business continuity, click HERE.
Rich Reiffer
Rich Reiffer is VP of Cloud Practice at Zenith Infotech. Rich has been in the business of technology since the dark ages starting with Burroughs Corp., spending time with Steve Jobs (NeXT) and Ray Noorda (Novell). Rich has been in the VAR channel since the mid 80's with companies like Inacomp and Businessland finally forming his own company, Trivalent, in 1991. After 20 years of building data centers, etc. Rich has come on board with Zenith to head up the Cloud group. Monthly guest blogs such as this one are part of Talkin' Cloud's annual platinum sponsorship.You May Also Like