More than just alternate infrastructure

More than just alternate infrastructure

DRaaS is more than a way to save money; to be a true service, it has to offer clients a solution that meets their needs and will work on the dreaded day of a disaster. What’s involved?

By Sasha Malic, Head: Availability Services, ContinuitySA

In my previous blog, I argued that the DRaaS model was extremely attractive because it allowed companies and government entities to access the alternate technology needed to keep them up and running in the event of a disaster. But I also made it clear that DR was more than just access to alternate technology—the solution must met the organisation’s needs, and it will have to guaranteed to work when it’s needed.

DRaaS makes accessing the alternate technology easy and less expensive, but it is still necessary to understand what data and applications are going to be recovered, and to what extent. Everything has its price tag, and its impact on the whole, so the whole system has to be properly understood. These are the key steps:

  • Perform a business impact assessment to understand the relative importance of all the business processes and applications in the organisation. This means ranking business processes (and the IT systems that underlie them) in light of their contribution to the business strategy. The next step would be to consult with the business owners of each process to understand how much downtime the organisation could tolerate for each process. At the end of this process, you will have not only the scope of the DRaaS solution but also the priority (and budget) of each component.
  • Set recovery targets in order to determine how rapid the failover to the DR systems would have to be (that is, how much time each application, and thus the business process it supports, can be unavailable), and how much data lost can be tolerated. The two main targets are thus the recovery time objective (RTO) and the recovery point objective (RPO). The RTO specifies how long the particular application can be down, and the RPO the maximum amount data that can be lost. While they are related, they do not have to have the same values. Thus, for example, the RTO might be 60 minutes and the RPO 10 minutes, meaning that while the system only has to be back up and running in an hour, only 10 minutes of data may be lost.
  • Identify security and compliance issues. The company remains responsible for the safety and proper use of data, particularly sensitive financial and personal data. Most countries have legislation governing this, and when the Protection of Personal Information Act comes into force, South Africa will be no exception. One implication is that critical data often has to be stored on servers that are physically located in the country of origin—this question of data sovereignty means that data can’t just go into the cloud, one needs to know where it is. Other legal issues might include who actually owns the data, who is responsible for protecting it, who can access it, how it may be used and how long it should be retained.
  • Ensure adequate network performance. It is critical that the links between your production and DR environments are sufficient to enable the DR system to operate effectively.

Next time, we’ll look at a final issue that needs to be resolved: which type of DRaaS you will opt for.

Leave a Reply

Your email address will not be published.