Products & Services Data Center Locations About
In an industry (IT) notorious for its abundance of acronyms, it’s easy to dismiss RPO and RTO as the same thing or, at the very least, not that much different from one another. Recovery point objective (RPO) and recovery time objective (RTO) do sound very similar. Both are key metrics in business continuity. Both involve a disruption to business in which data and/or systems are unavailable.
Is it that much different to recover data back to a certain point as opposed to recovering it in a certain amount of time so your business can be back up and running? The answer is a “yes,” and it’s because neither concept is solely about data recovery.
RPO refers to the point back in time from which you want your critical data restored after a system disruption or failure. It tells you how much time from the point of the outage you can afford to lose. RPO can be measured in intervals ranging from minutes, hours, or even days. A smaller RPO means that less data is lost, which is critical for normal business operations.
RPO determines the frequency with which you’ll need to replicate data from your production site to a DR site. To achieve a smaller RPO, you need more frequent backups. If your RPO for an application is one hour or less prior to disaster, you’ll need to replicate data at least hourly. If you can’t afford to lose any data, ever, you’ll need to implement synchronous replication for that application. That means your data must be written to a DR site at the same time it’s being written at your production site.
Keep in mind that the lapse after your last backup translates into lost data, and can have major repercussions if your business relies on that data for its normal operations. However, it’s not necessarily good business sense to back up everything or to back it all up frequently. The more frequently you back up, the more copies you must maintain. And, backups aren’t free.
RTO refers to how quickly you must restore access to data and IT systems after a disaster or other business-disrupting event occurs, so your business can be up and running again. In simple terms, it’s the maximum tolerable length of downtime following a disaster. It’s less about data loss, and more about having the application or data available. Not all data, applications and system have the same RTO, because some aren’t as important for day-to-day business continuity. Your internal data warehouse may need to come back online in several hours, while a customer-facing website may need to be back up immediately. By quantifying and ranking the RTOs for each critical process, you’ll be able to prioritize resources to restore the ones with lower RTOs before the rest of them.
To define RPO and RTO for your company, you’ll need to answer several questions. Among them: Which of your IT assets are most important for ensuring your business can keep operating? Which would you need access to first following a disaster? Which could wait? How long could you wait for access? Following these steps will help with the answers:
By understanding and defining your company’s RPO and RTO requirements, you can identify and put in place the resources needed to minimize the effects of any business-disrupting event, from a natural disaster to a cyber-attack. For more information, take advantage of these free resources from US Signal:
Or, talk to a US Signal expert. Call 866.2. SIGNAL or email [email protected].
The survey reveals security, disaster recovery and network availability are top priorities for companies when choosing a data center provider. Cost is also a key consideration, and 91 percent of respondents are likely to select a data center provider located close to their users.
Learn how cloud-based object storage can help meet the data storage component of your data management strategy.
A key step in data management is developing a data retention policy that specifies what to keep and for how long, and what to delete. Learn how to get started.
