The relationship between RTOs and RPOs

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Data storage backup tools HP expands laptop and desktop data backup with Data Protector Notebook Extension Data backup and recovery news briefs: Rackspace unveils cloud-based file storage apps EMC gives Avamar desktop and laptop support Terremark acquires managed data backup and recovery provider DS3 DataVaulting Data backup and recovery news briefs: Dynamic Solutions introduces data deduplication products Creating a System Recovery Disk in Windows 7: A step-by-step tutorial Modern data backup and recovery system considerations Data backup and recovery news briefs: Thales Group releases CryptoStor Tape 3.0 appliance Data archiving reduces data backup workload prior to data deduplication Symantec releases Linux version of Backup Exec System Recovery

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

The quick answer is that there's no "standard" ratio or relationship between a recovery time objective (RTO) and a recovery point objective (RPO). However, they aren't always independent of each other -- one can affect the other.

The RTO is the amount of time in which a system must be recovered in the event of an interruption. It's driven by the business and represents the maximum amount of time a company can tolerate an interruption of a business function or process that depends on the system. The RTO plays an important role in the development of data recovery strategies and is often used as the basis for the development of a service-level agreement (SLA).

An RPO is the point in time to which a system's data must be recovered after an outage (i.e., last night's backup, the last transaction before the outage, etc.). The RPO is often used as the basis for the development of data backup strategies. It's also used to determine the amount of data that may need to be recreated after the system is recovered or, ultimately, what constitutes acceptable data loss.

Depending on the type of application and the business function it supports, the RTO and RPO can be miles apart. For example, an application providing a critical service relying on static data may have an RTO of one hour, but an RPO of one day. The application must be up in one hour, but using yesterday's data is OK. Conversely, a four-hour email server outage may be tolerable to a company, but losing a single email message may be unacceptable for business or legal reasons. We end up with an RTO of four hours and RPO of zero (down to the last transaction).

Now with all that said, it's possible to miss a RTO while trying to meet a RPO. In other words, it takes so long to restore the data to meet the RPO that the application ends up being down longer than allowed. This is when we need to start rethinking our data recovery strategies.