A few weeks ago, my colleague Brice explained you the concept of RTO. In this blog I'd like to go a little deeper on how you can make up what your RTO should be.
Let's start with a small refresh about RTO because it is really important to fully understand the meaning of this concept. RTO stands for Recovery Time Objective. It refers to the point in time (in the future) at which you will be up and running again after a disaster in your IT infrastructure. So the calculation of your RTO may seem to be quite simple, but as always, it isn't as easy as it sounds.
As this time can vary from a few seconds for some to a few days for others, it's difficult to come with a standard way of calculating your RTO.
"If one thing can be clear, it is that the RTO should fit the company's needs"
- A first step in this exercise is to find out which applications and systems are critical. Ask yourself and your colleagues (of different departments) the next question: What is the impact for you and for your department if the IT infrastructure would be down during a whole day? The answers you will get will already give you a good indication about the range in which your RTO should be situated.
- A second step is to determine the losses which could occur if the IT infrastructure goes down. This isn't easy as we can't always quantify them (eg. damage of reputation).
After you've got the information, it is time to determine how long you can go on before these losses become inacceptable.
Once you've worked out the required recovery time for each application and system, your overall RTO can be calculated in two ways:
- If there’s one application that will cause significantly greater loss to your business than the others, you can use the recovery time for this application as your RTO.
- If there's no great difference you can average the recovery times for all application to get your RTO.
Last but not least, don't forget to test your solution to make sure you can reach the RTO you've set.
