Disaster Recovery Solutions

A disaster recovery option builds on managed backup by enabling this restore capability. The primary compute resources can exist on-premise, in colocation racks or on a cloud somewhere. The scenario remains the same: there has been a disaster at the primary site and all compute and storage resources (e.g. the on-premise server room) are offline or destroyed. Cloud-based DR exists to restore full services within the agreed customer SLA. This SLA is based on two determining factors: RPO and RTO.

RPO: Recovery Point Objective

RPO determines how far back the customer wishes to go to restore data from the backup – the recovery point in time – as part of their SLA. Note that this cannot be a timeframe more frequent than the backup schedule. So if the managed backup is scheduled for every 24 hours, the best-case RPO will be 24 hours. If the frequency is shorter, the RPO can be sooner. Some companies may choose to pay a higher fee for more frequent synchronisation allowing a shorter RPO window, e.g. a recovery point objective of 4 hours.

RTO: Recovery Time Objective

RTO determines how quickly the customer expects service to be restored, i.e. the compute resources are spun up and the data is live, with this being enshrined in SLA. An RTO of 4 hours is commonplace. Many companies pay more for an RTO of 1 hour. At its most extreme, some pay for a “live/live” environment where service can be cut across nearly instantaneously, but that is prohibitively expensive for most.
The agreed RPO and RTO combine to form the service level to which the customer expects the service provider to adhere. In short, it’s an indication of how far back to go and how quickly to restore. So a 24 hour RPO and 4 hour RTO would mean that the customer would expect data to be no more than 24 hours old and service to be restored in less than 4 hours.

The diagram below shows a typical scenario.

This example is fully converged – e.g. Six Degrees has delivered both telephony and IT resources. The primary environment could be on-premise, in a colo rack or on a cloud, the principle is the same and it’s on our backbone network.

All customer sites are networked with 6DG providing SIP trunks for voice transit. The secondary environment is our cloud platform where the data is backed up, along with the IP telephony call control, and virtual machines are reserved ready to restore service. The nature of the service restoration, the disaster recover service itself, is based on RPO and RTO.