Backup Considerations (Part 2)

Okay, so you can count yourself amongst the more enlightened readers. You have made the decision that you want your data backed up. You acknowledge that having a backup strategy in place is not going to generate income but you know that without having it there, you can’t sleep at night for fear of losing all your company’s data due to some of those circumstances mentioned in the preceding blog. You have been assured that you have backup by your IT provider and that’s that then…or is it? You have to ask yourself what happens when disaster strikes and you lose a server for whatever reason. You and you colleagues/employees cannot access anything that has ever been saved there, you can’t access any of the orders that have been made, never mind fulfil them; your customers are demanding service and you can’t provide it. The only consolation that you have is that you have it all backed up. Everything’s fine then, but have you asked yourself how does my backup transform itself back into my data? Well, you could refer to your Business Continuity/Disaster Recovery Plan (BC or DRP – have a look at international standards ISO 22301 to see what you are missing out on) where you would find useful information regarding just such a situation, such as who to contact and the amount of time it’s going to take to get you back up and running etc. Part of these plans is to state clearly what the expectations are for getting everything back to normal. It would specify the arrangements made to restore prioritised, critical business functions. I should introduce a couple of terms that should define the nature of your backup and help you clarify your expectations – Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Once you have defined these terms you should clearly understand where you are when it comes to re-establishing normal business function. These will dictate how the process of recovery will be fulfilled. So the RTO relates to the time between failure of the system and its re-instatement to a functional level. Say you lose the server at 14:30 in the afternoon and it is finally re-instated at 17:30. If your RTO (defined in your DRP) is 5 hours, then you will have achieved this with a bit to spare (2 hours in fact). The RPO is again predefined in your DR plan. Look at it as the level of data loss – I know there is no acceptable level of data loss but the practical returns on investment may be dwarfed by the cost of implementing a real-time solution, mirroring every keystroke. If for example losing an hour’s worth of work (let’s use that for our RPO) you estimate will cost the company £10,000 – is it worth implementing a solution that will cost you twice that a year that may never be called upon? So that’s the point of the RPO, you have to make that decision in conjunction with your IT provider. They can inform you of the actual cost of implementing the solution that’s best for you, the business and the profits. It is a balancing act, it is a strategic decision and it must be determined as early as possible and set out clearly in you BC/DRP. Everybody knows what to expect, who to expect it from and when. If you have any questions about this you can contact Excellimore Ltd. We have years of experience of establishing rock-solid back-ups, bringing your RPO down as low as 15 minutes and managing the system efficiently enough to ensure that these objectives are met should you find yourself in these unfortunate circumstances.