# # Michael Desrosiers
APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Recovery Time Objectives

I've removed advertising from most of this site and will eventually clean up the few pages where it remains.

While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.

If you found something useful today, please consider a small donation.



Some material is very old and may be incorrect today

© April 2009 Michael Desrosiers

This month's topic is Recovery Time Objectives (RTO), and how it relates to your Disaster Recovery Plan in establishing time constraints for your business critical applications.

What does Recovery Time Objective (RTO) mean exactly? We find this acronym in just about every discussion about backup products and storage arrays. Many IT people mistakenly think it refers to the time it takes to restore a system or an applications data. Although that is true, RTO and reality are sometimes not one in the same. The RTO is a goal or an ideal time in which you need a specific resource or service to be available following an interruption or outage. In essence, the RTO provides the maximum amount of time before an organization is negatively impacted by the interruption of one its core business processes or functions. For this reason, the task of establishing the RTO must start at the business level and not the systems level.

This information must be gathered from the various Business Units (BU) and then be analyzed. This analyze will help provide conclusions with respect to potential losses and the time frame from which they can be incurred. This Business Continuity Planning (BCP) process is known as a Business Impact Analysis (BIA), and should address the following items:

Business Units

Create a list of the various functions or processes for which the BU or department is responsible for revenue generating activities, and what happens when a specific business process or function is interrupted;

Possible Losses

Determine the financial or intangible losses an outage could cause. Financial losses include lost revenue, salaries paid to non-productive employees, extra expenses and fines. Intangible losses include damaged brand and reputation, negative public opinion or depreciated stocks;

Critical cycles

Consider the worst possible time at which an interruption could occur like at quarter-end or year-end in the BIA and RTO;

Dependencies

Identify applications required to perform or assist with a specific business function. Other dependencies include other business functions, services or key roles;

Prioritization of Dependencies

Identify how critical dependencies are to a particular business function. For example, unavailability of an application that is highly critical to the function may actually halt that function.

Workaround and Fixes

Create a manual process or documented contingency plan that could allow temporarily capabilities to a function, which would buy some time, thus allowing a longer RTO.

Once the potential losses have been identified, the business is in a position to make a decision regarding what it considers acceptable losses. Because losses are incurred over time, this decision also dictates the maximum outage the business can tolerate for each specific function. The RTO for the business functions must therefore not exceed that maximum tolerable outage. Subsequent dependencies identified as highly critical to these business functions, must also fall under the same RTO. It must also include the applications or other business functions and their respective applications. This is where the RTO for each application and supporting infrastructure must be prioritized and established.

So, there you have it. Recovery Time Objectives are a very critical piece of an organizations business recovery strategy. To provide reliability you should consider how you respond to procurement delays, as these elements can consume part of the RTO before the actual recovery effort is even initiated. One of the primary reasons why disaster recovery plans do so poorly, is the risk of taking shortcuts and burdening users already overloaded with other work. When a person's primary role is in conflict with their disaster recovery role, the primary role almost always wins.

To view more articles:

http://aplawrence.com/cgi-bin/getauthart.pl?Michael%20Desrosiers

or to inquire about an on-site presentation, please feel free to call me at 508-995-4933 or email me at [email protected]

Until next time.....

Regards,

Michael Desrosiers
Founder & Principal Consultant
m3ip, Inc.
Managing Your Security and Risk Needs
(O)508.995.4933
(C)774.644.0599
(F)508.995.4933
[email protected]
http://www.m3ipinc.com


If you found something useful today, please consider a small donation.



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

->
-> Michael Desrosiers


Inexpensive and informative Apple related e-books:

Sierra: A Take Control Crash Course

Take Control of iCloud

Take control of Apple TV, Second Edition

Digital Sharing Crash Course

Take Control of iCloud, Fifth Edition





More Articles by © Michael Desrosiers





Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us


Printer Friendly Version





The people I distrust most are those who want to improve our lives but have only one course of action in mind. (Frank Herbert)




Linux posts

Troubleshooting posts


This post tagged:

MDesrosiers

Security



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode