I just had a meeting with one of Alvaka’s IT consultants regarding the development of a disaster recovery and business continuity plan for a financial services client of hers. A year ago the client had a very nearly disastrous weather related IT event that could have slammed the whole company beyond imagination. During a heavy downpour a major leak opened up on the roof and dumped significant amounts of water right onto the client’s primary server rack. The servers were so flooded that during the recovery process the techs actually had to de-rack the servers and tilt them over in order to pour out the water. Full disaster was averted when
through careful drying of the hardware the systems miraculously restarted. They were lucky as the tape drives and tapes were all in the same racks as the servers. Worse yet, all of the tapes were destroyed in the flooding.
So, what is RTO and RPO and why is it important to you? RTO is an acronym for Recovery Time Objective. RTO is usually measured in minutes, hours or days and it represents the amount of time it is acceptable for your organization to be down and out of IT service. In other words, your RTO should be defined in terms of how fast you need to be back up and running in the event of a partial failure or total loss of your critical IT systems. Most organizations I talk with, commonly have RTOs of 15 minutes to one day, depending upon what business they are in and which systems are involved.
RPO stands for Recovery Point Objective. Your RPO should define how much data you can lose in the event of a failure. Again, most clients usually fall into a RPO range between 15 minutes and one day. Most will define varying RPOs depending upon what type of system is involved. Mail servers, database servers and accounting systems typically land in the 15 minute RPO range. DNS servers, remote access servers, etc. are usually fine with a one day RPO. Your requirements for your business will define what is right for you.
My next blog will discuss the nature of the RTO and RPO implications for this client that is looking to avert a future disaster.
Smoke testing is a term used to describe the testing process for servers after patches are applied. 
Estimating an average time for patching servers and PCs can be a bit tricky. It can vary from one month to the next, depending upon the number and complexity of the patches released by your software vendors. You must consider all versions of operating systems and have a complete inventory of all your application software to do this job correctly. Our experience has shown that manual patching of systems takes on average of about 1.5 hours each.
This is a basic cost calculator for you to compute your typical monthly cost for patching your servers, PCs, laptops, tablets and associated application software. It also forms the basis for you to begin calculating your Return on Investment for software patching, or for comparison with alternatives to the manual process of patching operating systems and application software—such as Patch Management as a Service, also known as Vulnerability Management as a Service.