In this article, we\u2019ll compare RTOs to RPOs and explain their key points and differences. We\u2019ll also explain how you can meet and incorporate them into your recovery and continuity planning. Or, if you’d like to skip to the chase, please check out Resilio solution for Disaster Recovery<\/a>. <\/p>\n\n\n\n A Recovery Time Objective (RTO) is the maximum length of time<\/strong> it should take to recover after an event such as an outage or data loss.<\/p>\n\n\n As you might imagine, having a tight RTO is a key goal for any IT infrastructure \u2014 especially those that support applications with high uptime requirements.<\/p>\n\n\n\n When a system goes down in an unplanned outage, the organization\u2019s RTO serves as a benchmark for how quickly it should recover and resume normal operations.<\/p>\n\n\n\n RTOs vary depending on two major factors:<\/p>\n\n\n\n These two factors are highly connected. While most organizations aim for RTOs set to within an hour, systems with the highest priority (Tier 1) might have RTOs as low as 5-10 minutes.<\/p>\n\n\n\n Conversely, RTOs for less critical (Tiers 2 and 3) systems might be as long as four hours or even up to an entire day. Again, it all comes down to the organization\u2019s cost of downtime, which can include things like loss of revenue, lost data, or risk to life in the case of medical technology.<\/p>\n\n\n\n Note that RTOs aren\u2019t directly concerned with data loss \u2014 that\u2019s more the job of RPOs, which is why RTOs and RPOs are both<\/em> crucial to DR plans. We\u2019ll cover RPOs in depth later on, but know that RTOs can have an indirect impact on RPOs if the time to recovery impacts the data loss in some way.<\/p>\n\n\n\n As mentioned previously, calculating RTOs depends on the cost of downtime and system priority.<\/p>\n\n\n\n Most organizations use a system\u2019s priority or tier <\/em>as the starting point, as this usually informs the cost and impact of downtime. Typical tiers and their respective RTOs include:<\/p>\n\n\n\n Of course, these are only guidelines. One organization\u2019s Tier 1 RTO might not take as long as another\u2019s.<\/p>\n\n\n\n For example, an insurance company\u2019s customer portal (a Tier 1 system) might have an RTO exceeding one hour, as an hour or two of downtime likely won\u2019t affect revenue in a significant way. However, an hour would be much too long for a major online retailer, where even five minutes of downtime can mean thousands of dollars in lost revenue.<\/p>\n\n\n\n It\u2019s one thing to have an RTO of 10 minutes \u2014 but it\u2019s another thing to actually meet it.<\/p>\n\n\n\n Unfortunately, calculating and setting an RTO isn\u2019t quite as simple as saying, \u201cThis system should be fully recovered within 15 minutes of an outage.\u201d Not only is that easier said than done, but certain events might make meeting RTOs extremely difficult or impossible. Your IT architecture plays a big roll–from storage architecture to applications. But one thing is certain. Being prepared helps. Whether that be through an on-prem or cloud DR solution<\/a>. <\/p>\n\n\n\n Fires and natural disasters are extreme examples, of course, but they raise an important point. Rather than making your RTOs firm requirements, they\u2019re better used as general guidelines for deciding how many resources to allocate to certain systems in an emergency.<\/p>\n\n\n\n But which systems deserve the most resources? While we\u2019ve already covered system tiers and their respective RTOs, it may not always be clear which system is in which tier. While Tier 1 systems tend to be pretty obvious, what makes a Tier 2 or Tier 3 system is often subjective.<\/p>\n\n\n\n While there isn\u2019t one answer, the following strategy can help match your RTOs to the right systems.<\/p>\n\n\n\n 1. Take a complete inventory of your systems.<\/strong>\u00a0What does your IT infrastructure look like? Are you using an on-premises system, a cloud-based solution<\/a>, or both? How many systems do you have, and who supports them? These are just a few of the questions you should ask to not only clarify your topology but also to understand (a) what\u2019s at risk and (b) the unique specifications and recovery requirements of each system.<\/p>\n\n\n\n 2. Assess the priority of each system. <\/strong>Even if you\u2019ve already assigned system priorities or tiers, they\u2019re still worth regular review \u2014 especially as things change. You may also want to prioritize systems and applications that are necessary to the recovery process, such as any file synchronization<\/a> or backup tools you may use. Generally, you should prioritize systems that will have the greatest impact on recovery time.<\/p>\n\n\n\n 3. Understand potential risks to your systems.<\/strong> Understanding the inherent risks to your systems and applications is crucial for mitigating them. For example, on-premises systems stand the risk of downtime and data loss in the event of a power failure. In such a case, meeting your RTOs might mean having a backup power supply.<\/p>\n\n\n\n 4. Review recovery solutions and capabilities<\/strong>. What tools will you use in the event of an outage? Who is responsible for what? Does each system have different recovery tools or personnel? In any case, you should know what tools and resources are at your disposal in an emergency \u2014 as well as their limitations.<\/p>\n\n\n\n 5. Assign RTOs and resources carefully.<\/strong> With a complete view of your infrastructure from a disaster recovery perspective, you can finally assign your RTOs based on system priority and available resources. Though Tier 1 systems should almost always get immediate attention, don\u2019t neglect Tier 2 systems that might be necessary for recovery efforts.<\/p>\n\n\n\n Quick recovery times can come at a cost.<\/p>\n\n\n\n Generally, the more stringent the recovery objective, the costlier it is to meet. This is true for both RTOs and <\/em>RPOs \u2014 whereas meeting RPOs requires budgeting for frequent backups, meeting RTOs requires budgeting for anything <\/em>that may help minimize downtime. That could mean maintaining redundant servers or using file synchronization tools.<\/p>\n\n\n\n As you might imagine, meeting RTOs is generally much costlier than meeting RPOs, as RPOs usually just require maintaining frequent backups. By contrast, RTOs often involve enterprise-wide efforts involving a combination of tools, infrastructure, and personnel \u2014 all of which must be available at a moment\u2019s notice.<\/p>\n\n\n\n Without the right recovery tools in place, even the most well-intentioned RTOs can end up spanning several days.<\/p>\n\n\n\n One Resilio customer<\/a> was able to solve this exact problem with Resilio Connect. By replacing their slow DFS replication with Resilio\u2019s file synchronization tools<\/a>, the company was able to reduce their three-to-four-day recovery time to mere minutes.<\/p>\n\n\n\n A Recovery Point Objective (RPO) is the maximum data loss tolerance <\/strong>an organization can withstand after an event.<\/p>\n\n\n Though data loss and recovery time are often interdependent, an RPO focuses on data loss alone. Even if a slow recovery time results <\/em>in additional data loss, all we\u2019re worried about here is how much <\/em>data was lost.<\/p>\n\n\n\n Of course, that doesn\u2019t mean recovery time and RTOs don\u2019t play a pivotal role in meeting RPOs. But before we get into that, let\u2019s explore what it means to use data loss as a benchmark.<\/p>\n\n\n\n When a system or application experiences an outage or suffers from data loss, the organization\u2019s RPO sets a benchmark for how much data it can stand to lose \u2014 and how much it can recover.<\/p>\n\n\n\n Like RTOs, RPOs use the cost of data loss as a major factor. However, since data impacts everything from personal information to regulatory compliance, the factors for determining RPOs are slightly more varied.<\/p>\n\n\n\n Here are a few major factors that might impact your RPOs.<\/p>\n\n\n\n The most important of these factors are the cost of data loss and the maximum tolerable data loss. Of course, these two factors are closely linked, as increasing data loss can come with increased costs.<\/p>\n\n\n\n Your storage options will also have a significant effect on your RPOs. For example, an on-premises server with hourly backups will have a significantly larger RPO than a cloud solution<\/a> with backups every minute. In any case, the capabilities (namely backup frequency) of your storage solutions will place a fairly strict limit on your RPOs.<\/p>\n\n\n\n Depending on your industry, your RPOs may also be subject to industry-specific regulatory requirements. For example, regulations and standards such as the General Data Protection Requirement (GDPR)<\/a> and ISO 27001<\/a> usually require some form of disaster recovery planning (read: RPOs) and reliable data access. Inadequate RPOs can cause organizations to fall out of compliance in these areas.<\/p>\n\n\n\n So now that we know what affects RPOs, what do RPOs actually look like?<\/p>\n\n\n\n Just like RTOs, RPOs vary depending on system priorities and, more accurately, the importance of the data itself. However, since we\u2019re dealing in terms of data loss rather than time to recovery, calculating RPOs comes down to two major points:<\/p>\n\n\n\n Unlike <\/em>RTOs, however, RPOs can\u2019t be grouped into generalized tiers (10 minutes for Tier 1, 1 hour for Tier 2, etc.). Much of this is because the maximum tolerable data loss varies widely between organizations.<\/p>\n\n\n\n For example, a small accounting firm working with an Excel spreadsheet could have an RPO in the order of kilobytes, since most of the data lost would be spreadsheet entries since the last backup. By contrast, the RPO of a game development company could easily be in the order of gigabytes (or even terabytes) due to the high volume of media-rich files they work with.<\/p>\n\n\n\n When it comes to calculating your own RPOs, you should consider the average amount of data you process or add between backups. As you can probably imagine, frequent backups are the key to a small RPO \u2014 after all, you probably won\u2019t lose much data in an outage if your backups are only minutes apart.<\/p>\n\n\n\n Assigning RPOs is relatively simple: If you know how much data gets changed or added between backups, then you probably have a good idea of your RPOs.<\/p>\n\n\n\n However, it\u2019s not always so simple. Most organizations deal with a wide range of diverse systems and storage solutions, each of which may have its own frequency of backup. As a result, each system usually has its own inherent RPO, making assigning RPOs more a matter of system analysis rather than strategic planning.<\/p>\n\n\n\n In any case, the following procedure can help you determine the right RPOs for different systems in your infrastructure:<\/p>\n\n\n\n 1. Segment your infrastructure by types of data storage.<\/strong> Whether you have a single on-premises server or a vast hybrid model of physical and cloud servers, it\u2019s useful to gather a top-down view of how many different ways you store (and, more specifically, back up) your data. These segments will help inform how you allocate RPOs later on.<\/p>\n\n\n\n 2. List the backup frequency of each storage system.<\/strong> Every discrete storage system will have its own backup capabilities \u2014 even between two of the same type of system (e.g., two cloud-based servers). Here, your RPOs will likely be determined by the systems with the least <\/em>backup frequency. For example, even if you have a few lightning-fast cloud servers, your RPOs could be limited if your most critical data is in a slower, on-premises server with less frequent backups.<\/p>\n\n\n\n 3. Calculate the volume of data changed between backups.<\/strong> The previous step determines the time <\/em>between backups. This step determines how much data changes<\/em> between backups. This is a crucial layer of distinction, as a high backup frequency means little to your RPOs if there\u2019s very little data being processed. On that merit, your most crucial systems will be those in which a high volume of data is processed between backups.<\/p>\n\n\n\n 4. Consider the ease of reverting to backups.<\/strong> Even if you have frequent backups, how easy is it to revert to the preceding backup in an emergency? While systems with frequent backups usually have equally quick rollback capabilities, it\u2019s an important factor to consider for systems where restoring a backup could take an extended time period (and even impact RTOs).<\/p>\n\n\n\n 5. Identify opportunities for increasing backup frequency.<\/strong> No matter how much or how little data your systems process, increasing backup frequency will always be key to a small RPO. As you walk through your systems and their backup capabilities, try to identify opportunities for implementing file synchronization and other tools for narrowing the gap between backups.<\/p>\n\n\n\n Meeting RPOs is generally much less expensive than meeting RTOs.<\/p>\n\n\n\n Whereas meeting RTOs requires cooperation across an entire organization, meeting RPOs usually comes down to increasing backup frequency and reliability in individual systems. As a result, the cost of meeting RPOs is tied to the cost of the systems themselves. <\/p>\n\n\n\n For example, if you have an on-premises server or an otherwise slow distributed file system (DFS), then meeting your RPOs may require paying for upgraded file synchronization or migrating to a different infrastructure altogether. However, that doesn\u2019t mean the cost of doing so will be purely to meet your RPOs \u2014 instead, meeting RPOs is a natural result of investing in more efficient, reliable systems.<\/p>\n\n\n\n To sum up, here are the key differences between RTOs and RPOs:<\/p>\n\n\n Now let\u2019s look at how you can meet RTOs and RPOs in the next section.<\/p>\n\n\n\n Though meeting RTOs and RPOs are two different things, they share several common strategies.<\/p>\n\n\n In many cases, backup capabilities and time to recovery are closely linked. If you have frequent, readily available backups, then both your data loss (RPO) and recovery time (RTO) will be relatively small.<\/p>\n\n\n\n Consider the following tips in your disaster recovery strategy<\/a> to meet both RTOs and RPOs:<\/p>\n\n\n\n Your system\u2019s backup parameters are arguably the most important factor in meeting your RPOs \u2014 and, in some cases, your RTOs as well.<\/p>\n\n\n\n Though the exact backup parameters you choose will vary depending on your data, industry, and requirements, it\u2019s best practice to have at a minimum:<\/p>\n\n\n\n You may have a nice reserve of data backups and even some recovery policies and procedures. That\u2019s a great start, but it may not be enough.<\/p>\n\n\n\n Your recovery processes are only as good as your (and your organization\u2019s) familiarity with them in a disaster. In other words, if your recovery processes aren\u2019t clear or fine-tuned, then all of your good planning is useless \u2014 and your RTOs and RPOs will be long gone.<\/p>\n\n\n\n To avoid scrambling at the last minute, regularly review and practice your recovery processes with everyone <\/em>involved. And don\u2019t set your recovery processes in stone, either: look for feedback from those involved and try to identify room for improvement or areas where new tools can improve recovery time.<\/p>\n\n\n\n In a perfect world, we could simply maintain backups and snapshots in real time so that we could instantly recover from any disaster.<\/p>\n\n\n\n Unfortunately, this is more or less impossible short of some very <\/em>high-end cloud solutions. As a result, you\u2019ll need to budget your storage and snapshots wisely, as these will both come at a cost to data processing, storage, and so on.<\/p>\n\n\n\n Besides giving more resources to more critical data, it may also help to keep older backups in local storage to minimize load on live systems. This practice is becoming especially economical as large-capacity hard drives become more affordable.<\/p>\n\n\n\n If there\u2019s one concrete rule of backups, it\u2019s that you should always <\/em>maintain a 3-2-1 backup strategy. That means keeping at least:<\/p>\n\n\n\n Note the \u201cat least\u201d phrasing here \u2014 the 3-2-1 rule is the bare minimum for reliable backups.<\/p>\n\n\n\n It may seem obvious, but the practice of adding RTOs and RPOs can make a big difference in your recovery planning.<\/p>\n\n\n Beyond setting expectations, the process of calculating and assigning recovery objectives can give you a better idea of your recovery capabilities \u2014 information that can better inform your recovery procedures and help you identify areas for improvement.<\/p>\n\n\n\n But which objectives go where? While RTOs and RPOs are key to most recovery and continuity plans, they\u2019re especially effective in the following areas.<\/p>\n\n\n\n Note that simply adding RTOs and RPOs to your plans is only the start. As we mentioned earlier, it\u2019s crucial to regularly verify and update these plans to help you stay prepared and informed of new risks and realms.<\/p>\n\n\n\n From getting your systems back online to restoring the most recent backup, speed and efficiency are the keys to meeting your RTOs and RPOs.<\/p>\n\n\n\n Resilio\u2019s low latency, real-time file replication solution for DR<\/a> protects files of any type and size across sites to meet sub-five-second RPOs and RTOs within minutes of an outage. Resilio\u2019s highly resilient, peer-to-peer (P2P) architecture eliminates single points of failure to protect files in production environments in the event of an outage. Organizations may use any type of server, storage, on-prem data center, or cloud. <\/p>\n\n\n\nWhat is an RTO?<\/h2>\n\n\n\n
![\"Timeline](\"https:\/\/blog.resilio.com\/wp-content\/uploads\/2022\/10\/Recovery-Time-Objective-RTO.png\" "\\"Recovery")
<\/figure>\n<\/div>\n\n\nRecovery time as a benchmark<\/h3>\n\n\n\n
Calculating RTOs<\/h3>\n\n\n\n
Assigning RTOs<\/h3>\n\n\n\n
Cost of meeting RTOs<\/h3>\n\n\n\n
What is an RPO?<\/h2>\n\n\n\n
![\"Timeline](\"https:\/\/blog.resilio.com\/wp-content\/uploads\/2022\/10\/Recovery-Point-Objective-RPO.png\" "\\"Recovery")
<\/figure>\n<\/div>\n\n\nData loss as a benchmark<\/h3>\n\n\n\n
Calculating RPOs<\/h3>\n\n\n\n
Assigning RPOs<\/h3>\n\n\n\n
Cost of meeting RPOs<\/h3>\n\n\n\n
![\"Key](\"https:\/\/blog.resilio.com\/wp-content\/uploads\/2022\/10\/RTO-vs-RPO-differences.png\" "\\"RTO")
<\/figure>\n<\/div>\n\n\n5 tips for meeting RTOs and RPOs<\/h2>\n\n\n\n
![\"Tips](\"https:\/\/blog.resilio.com\/wp-content\/uploads\/2022\/10\/RTO-and-RPO-Tips.png\" "\\"RTO")
<\/figure>\n<\/div>\n\n\n1. Fine-tune your backup parameters<\/h3>\n\n\n\n
2. Optimize your recovery processes<\/h3>\n\n\n\n
3. Budget storage and snapshots wisely<\/h3>\n\n\n\n
4. Maintain a 3-2-1 backup strategy<\/h3>\n\n\n\n
5. Add RTOs\/RPOs to your disaster recovery and business continuity plan<\/h3>\n\n\n\n
![\"The](\"https:\/\/blog.resilio.com\/wp-content\/uploads\/2022\/10\/RTO-and-RPO-in-Planning.png\" "\\"RTO")
<\/figure>\n<\/div>\n\n\nProtect Files and Recover Faster with Resilio Connect<\/h2>\n\n\n\n