Wednesday, September 5, 2012

Backup RTO and RPO explained

Recovery Time Objective

This is a critical metric for illustrating the risk of potential downtime.  SNIA defines the term as follows:

The maximum acceptable time period required to bring one or more applications and associated data back from an outage to a correct operational state

Thus RTO is a measure of how fast data can be recovered.  As you can imagine, there are a range of options for reducing RTO and in general, the shorter the RTO, the higher the cost.  Common solutions for RTO reduction include, disk-based backup, CDP technology and array-based snapshots.  Each of those approaches bring a benefits in RTO, but may add capital expense and operational complexity.

The other element to consider is that not all applications should be treated the same.  For example, RTO requirements on a mission-critical Oracle database are likely to be very different from those on filers holding personal data.  In the former case, a lengthy outage could dramatically impact the business while in the latter, it could cause annoyance with a minimal business impact.

When considering a solution you should look at its RTO metrics and analyze how they align with your business objectives.  Additionally, remember that RTO and product cost are often inversely related and so while a short RTO might be nice for all applications, the resulting costs may not meet your budgetary requirements.

Recovery Point Objective

RPO addresses the granularity of recovery and the frequency of backup.  SNIA defines it as follows:

The maximum acceptable time period prior to a failure or disaster during which changes to data may be lost as a consequence of recovery.

The question to ask yourself is, “how much data can I afford to lose if an outage were to occur.”  In the traditional nightly backup model, you are potentially at risk of losing up to 24 hours worth of data.  You could reduce the RPO by performing more frequent backups during the day.  Alternative approaches include CDP or snapshots.  However, these can add cost and complexity.

Like RTO, RPO requirements can vary by application.  Critical applications with large change rates may require shorter RPOs versus infrequently changing lower tier applications.  Meeting these divergent needs typically requires different approaches to creating data backups.  However, in general the more granular the RPO, the more expensive the solution.  Thus, RPO must be reviewed in the context of application criticality and budget.

Read more

No comments: