We recently saw why RTO, Recovery Time Objective is an important factor for running a profitable business. Let us now explore some of the best practices related to it with the ServiceDesk Plus’s perspective candidly.

There are two important factors that we will have to consider in this case:

Allowed Downtime/Affordable Downtime before the systems when can be bought online and Recovery Time - The time is taken to bring systems back online realistically.

Strategically speaking, all business owners will want the Allowed-Downtime to be 0-seconds. 

However, that is not possible realistically. There is always time spent observing and declaring a disaster. Then there is time spent recovering the system. Ergo, it is impossible for 0-second recovery. Because of which, it is important to realistically plan the Affordable Downtime considering the cost to business.

As a practice in the Service Industry, vendors promise recovery time and up-time fulfillment. Even in some cases, Planned Maintenance Percentages and Promised Upkeep Service Level Agreements are charted and signed in the vendor contract. And this is based strictly on the contract. But to be able to chart such a contract, a realistic Allowed Downtime calculation is a must.

The next major factor, Recovery Time, is going to be strictly based on the method of recovery employed. Do you have two servers that are clones of each other? Are you going to simply spin up the clone and start using them? Fine! But it should be on paper as a plan, metaphorically at least!

There are various best practices that we can follow when it comes to effective recovery. We will discuss them in general and concerning a web app like ServiceDesk Plus as well in this series of articles.

There are multiple ways recovery can be done in our faithful application, ServiceDesk Plus and on the whole, it depends on the type of failure and the database used as the back end.

If there is a complete failure in the system with no access to the present production’s data/server, then a system failure can be declared. In which case, a recovery can be instructed. But if there is access to the server itself, but the app alone is down, then the vendor (us the support team) must be contacted for troubleshooting first and declaring that recovery is a must.

We will discuss the possible methods, pros and cons and also some general best practices irrespective of the methods involved in Part 2: Recovery Time Objective - Plan of Action.

For everything else related to ITSM and ServiceDesk Plus, do stay on watch for our posts!