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.
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:
Last but not least, don't forget to test your solution to make sure you can reach the RTO you've set.