Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) are design and test time implementations of a data protection infrastructure. These two measures are disaster recovery metrics that define the expectations of the organization around the recovery of data.
The recovery point objective (RPO) can be described as the maximum acceptable level of data loss following a disaster or a technical disruption of computing systems. The point in time could be a point of recovery that immediately precedes the crash or an appropriate time when the system was healthy. Recovery Time objective (RTO) defines the time frame for recovery of computing systems to ensure continuity of the business. Both these objectives, of course can be achieved only if the equipment and applications remain undamaged or accessible.
These quantifiable measures help organizations appreciate the complexity and risks of data backup and recovery in a scenario where optimized disk to disk storage systems, de-duplication, continuous data protection technologies, application backups, snapshots, replicas and a host of other components are seamlessly integrated to define the contours of the data protection system. These measures also help assess the organizations risk appetite and requirements and arrive at fairly accurate measures of costs in terms of time to recover. Many small, medium and even large organizations deploy data backup and recovery infrastructure with little or no understanding of recovery time objectives and recovery point objectives. In short, they often put the cart before the horse.
However, it should be remembered that RPO and RTO are not isolated components of backup and recovery systems. They are defined by the larger schema and design of the Business Continuity analysis. During the analytical phase of defining business metrics, critical business processes, systems, personnel, records and data are identified; contractual agreements and recovery priorities are examined and re-examined; internal and external dependencies are documented; and financial impacts are quantified. Finally, recovery time objectives and recovery point objectives for different systems are identified and groups with target levels are put in place. The process is often iterative and requires repeated evaluation by key business users and the senior management.
The design phase of RPO and RTO begins with mapping the metrics to the technology. Relevant systems, applications, databases, networks, storage tiers and supporting technologies are identified to create the backbone of the data backup and recovery infrastructure. Business processes are mapped to applications and applications are mapped to recovery time objectives and recovery point objectives with focus on rollback requirements or referential integrity considerations. Recovery solutions are then designed around these factors and differing technologies are integrated to meet the demands of the RTO/RPO targets.
It should be noted that the final design of the RTO/RPO system will emerge only from iterative testing and re-design. This could span a few weeks to a few months with repeated returns to the table for re-design and re-testing. Finally representative test scenarios will have to be used to freeze the design and examine compliance levels of the data backup and recovery infrastructure to the defined metrics.
The bottom line is that elaborate disaster recovery infrastructures will not serve the purpose for which they have been set up if the RTO/RPO have not been analysed and considered in the very design and deployment of the systems.
SecurStore provides a bespoke offsite backup solution catered for customers who have both mission-critical data and non-critical data i.e. it provides customers with a secure & efficient backup and recovery solution which is sustainable over time. This coupled with agentless technology and advanced support for all environments and applications makes it suitable for any type of business, data centre provider or reseller.