Sign on the bottom line

Disaster-recovery solutions require several complex, moving parts coordinated between your production site and the recovery site. Service-level agreements are ultimately the most accurate way to determine where responsibility is held for disaster-recovery process and execution. It’s important to have SLA documentation around these critical aspects of recovery so that customers have commitments from their vendor. It’s also important that a service provider’s agreements contain service-credit backed SLAs for additional accountability. When considering DRaaS vendors, ask your potential partner how far they are willing to go in protecting your business and your data, and if these promises will be reimbursable if not met. Bluelock's Brandon Jeffress reviews what is essential to be in an ironclad SLA.

Thinkstock

Infrastructure availability SLA

Infrastructure is the foundation upon which companies replicate and recover their data, so it needs to be running, especially during a recovery event when your replication site becomes your production site. If customers are buying DRaaS and data is being replicated to somewhere other than their own datacenter, there needs to be a service-level agreement (SLA). Infrastructure availability is often the baseline of all SLAs and for customers buying self-service DRaaS, this may be the only SLA that’s offered.

Thinkstock

Replication service SLA

Replication requires that both the technology at the production source site and the DR site target be maintained to ensure success. For this reason, a reliable DRaaS provider should consider replication services as part of the uptime availability promise for customers. If there’s no SLA in place to ensure successful replication, a customer could find themselves doing everything right on their side, and out of luck if the provider has not maintained their side with the same level of effort.

Thinkstock

Recovery team response SLA

Leveraging a managed service provider for DRaaS should feel like the customer’s IT team just grew exponentially, and for this reason there should be an SLA to ensure the provider will be there at the time of an event. For companies using self-service DRaaS, there’s no need for this SLA because this will be solely their responsibility. But for those using managed DRaaS models, this is a critical point to hold vendors accountable because the protection of data and systems availability heavily depends on quick execution during an event, especially if your IT team is rendered unavailable to execute the recovery process.

Thinkstock

Recovery Time Objective SLA

Recovery time objective (RTO) definitions vary based on the DRaaS provider, so you need to understand what your provider is really offering. Few offer an RTO SLA that covers infrastructure availability, booting virtual machines (VMs), booting operating systems, starting the applications and quality assurance that equates to a customer’s applications returning to normal usage. Most providers limit their RTO SLAs to a subset of that list or, in some cases, only include booting the VMs. Since this SLA promise for RTO will vary in the marketplace, challenge your DRaaS provider to understand what your business cares most about and ask what they are willing to commit to in writing.

Thinkstock

SLA service credits

What if your DRaaS provider fails to meet expectations? This is the primary reason why it’s important that a service provider’s agreements also contain service-credit backed SLAs. This reimbursement for any unmet SLAs will add a level of accountability, since the DRaaS provider will have more at stake than your retention.