5 IT Disaster Recovery Measurements to Know

Disaster recovery is a major component of the systems administrator’s role. These IT pros must collect and correlate information to discover actionable results. Various disaster recovery tools are used to measure results, predict failure and anticipate recovery time. Organizations use these measures to plan resource allocation and service availability.

A note on metrics: One essential tool used for disaster management is metrics. It’s critical to track metrics for failures to mitigate future issues. In many cases, these metrics will only be good as a general baseline. It’s also important to recognize that these metrics will not necessarily tell you why an issue occurred or how the issue was ultimately resolved. Finally, the metrics are only as good as the data you collect regarding incidents, downtime, restore time, response time, etc.

There are a variety of nontechnical terms associated with data gathered for incident and disaster planning. Systems administrators are used to the usual IT acronyms—IP, HTTP, DNS, PEBKAC, etc.—but what about other less computer and network-specific terms?

Let’s take a look at five common disaster recovery (DR) terms and summarize their meanings. We’ll also provide ideas for improving DR response for the areas measured. These tools rely on the metrics your organization gathers.

Five common DR terms:

• Mean Time Between Failure (MTBF)
• Mean Time To Failure (MTTF)
• Mean Time To Recovery (MTTR)
• Recovery Point Objective (RPO)
• Recovery Time Objective (RTO)

Mean Time Between Failure (MTBF)

MTBF measures the mean time between repairable product or service failures. Let’s be clear, this is not scheduled downtime and it is not non-repairable failures. For example, a laptop that has been destroyed by an event does not count for MTBF.

The goal behind tracking MTBF is to predict reliability and availability based on the knowledge that there will be a failure at some point. Such information is useful to buyers to ensure they are receiving a reliable product, internal support teams to identify support issues and product sellers to recommend a product service or repair schedule.

MTBF = operational time/number of failures

MTBF can be improved by various means, including:

• Proactive service and maintenance
• Quality components
• Using the system within its design parameters
• Proper environmental conditions

Mean Time to Failure (MTTF)

MTTF is a different measurement from MTBF. This metric covers non-repairable failures and thus it measures the total lifespan of a system. MTTF also does not cover scheduled downtime. Instead, the goal is to anticipate value and replacement time for systems—information that is valuable to buyers and sellers alike. Some organizations will use this information as part of their budgeting process to ensure they are replacing devices before the end of their estimated lifespan.

The formula for MTTF is:

MTTF = total hours of operation/total number of units

MTTF can be improved by following the following practices:

• Quality components
• Properly installed components
• Using the system within its design parameters

Mean Time To Recovery (MTTR)

Let’s address the MTTR acronym first. In various situations, the R in MTTR can stand for repair, recovery, respond or resolve. In this example, we’ll be using the word recovery.

MTTR is a common term that is used to measure a system’s maintainability from both a product and a support perspective. It tracks the system’s reliability as well as the support staff’s responses to help determine how much effort may be required to support a given product and to evaluate the troubleshooting process. MTTR may indicate that it takes too long for your system to be recovered, but not why it took so long or why a system might be failing frequently.

The formula for MTTR is:

MTTR = downtime/number of repairs

It represents the full downtime of a system, from failure to complete recovery. The goal is to keep this value as low as possible.

MTTR can be improved by following the following practices:

• Stockpile known-good spare parts
• Improve monitoring for quicker detection and more reliable data
• Streamline the recovery process
• Retain trained and knowledgeable technicians and administrators

The next two terms are Recovery Point Objective (RPO) and Recovery Time Objective (RTO). Where the various “mean time” metrics cover actual values, these two objectives define goals that the organization strives to meet as part of business continuity planning. These goals can be realistically set by interpreting data gathered from the above topics.

Recovery Point Objective (RPO)

The RPO sounds harsh. It defines the quantity of data (or service time) that can be lost before unacceptable consequences occur. This is usually oriented on backups. For example, an organization might decide that standard user data (word processing documents, spreadsheets, images, etc.) will be backed up every 24 hours. That means the company is willing to accept the cost of up to 24 hours of lost data. If that were unacceptable, the RPO (and therefore the backups) might be set at 12 hours. The RPO is met by configuring regular backups and possibly implementing data replication.

Note: When planning data backups, consider the 3-2-1 Rule. This rule states that there should be three copies of data, stored in two different places, where one of those places is off-site.

Recovery Time Objective (RTO)

RTO measures the quantity of time that passes during an incident before reaching the business continuity plan’s (BCP) threshold of acceptability. The RTO kicks in when the incident begins and provides guidance for how quickly a particular issue must be solved. This value is then used to calculate support and recovery costs. For example, if a given service must be recovered within two hours of a failure, then 24-hour support must be made available (and funded).

There are some related factors with RPO and RTO values. These should be considered in the company’s BCP and DR objectives and include:

• Legal or regulatory compliance
• Service level agreement compliance
• Cost of disaster recovery solutions
• Cost of data or service loss

How to Use These Concepts

Understanding these terms is just the first step. Once you’re comfortable with DR concepts, the next step is to review your company’s existing disaster recovery and business continuity plans. All too often you will discover either a badly outdated plan or no plan at all. You will also need to evaluate how your organization gathers support and recovery metrics to ensure actionable information is gathered.

Your organization’s ability to predict failure, maintenance windows and recovery times is based on the quality of data gathered. Some metrics are available from vendors and others you’ll have to gather for yourself. Understanding common failures and how long it takes to recover from those failures impacts staffing, funding, purchasing, compliance and service level agreements. Combined, these areas have a tangible effect on your IT organization and priorities.

These disaster recovery terms are covered by CompTIA Network+ (N10-008). Learn about these and more skills needed by systems administrators, network administrators, systems engineers and network support specialists with CompTIA CertMaster Learn for Network+. Sign up for a free 30-day trial today.