Recovery time objectives

Increasingly, service levels around availability are driven by the mean time to recovery. Recovery time objective, commonly abbreviated as the RTO is the duration that it takes to bring the system back to its operational state. Recovery point objective or RPO is the amount of data loss that the service level agreement allows for. If my system fails at 10:00am and is restored by noon from tape backups from midnight, RTO would be 2 hours and RPO would be 10 hours. Minimising recovery time and data loss requires close cooperation between applications and operations teams.

Developers need to work in concert with their operations counterparts in designing recovery procedures to ensure seamless operations. If availability is built into the application design, you can eliminate not only the unplanned downtime but “planned” downtime as well. Planned downtime is needed for activities including upgrades, migrations, or maintenance work on the application, database, or operating systems. For example, a one-hour maintenance outage every other week will add up to 26 hours annually that the application is not available. Instead, if the application facilitates seamless switchover between primary and secondary systems, maintenance can be carried out without any outages.

A clear delineation between data and application logic can provide a great deal of improvement. If applications are designed to delegate management of data persistence to the database, data availability and application availability can be handled separately. Application binaries don’t change very often; if application data is kept in a database, recovery point becomes a database-driven concern.

For continuous availability of the underlying data, approaches such as transactional data management (TDM) offer solutions to eliminate both planned and unplanned outages. Databases can be configured in a shared-nothing topology while kept fully synchronised with such options as conflict detection and resolution for active-active deployments. By switching the applications across synchronised instances of the database, underlying databases, operating systems, and hardware can be serviced without taking the application off-line.

As applications increasingly become a service, developers have to build continuously available applications. The focus is shifting from fault tolerance to also reducing mean time to recovery; this paves the way to eliminating not only unplanned but also planned outages. Development work only pays-off when the deployment and operations is successful and building continuously available applications requires software developers and operations staff to work closer than ever!

www.goldengate.com