{"id":4032,"date":"2014-09-10T14:00:00","date_gmt":"2014-09-10T14:00:00","guid":{"rendered":"http:\/\/www.backupassist.com\/blog\/?p=4032"},"modified":"2019-11-07T07:31:30","modified_gmt":"2019-11-07T07:31:30","slug":"calculating-rto-rpo-make-bulletproof-business","status":"publish","type":"post","link":"https:\/\/www.backupassist.com\/blog\/calculating-rto-rpo-make-bulletproof-business","title":{"rendered":"Calculating RTO\/RPO \u2013 make IT bulletproof for business"},"content":{"rendered":"

\"Calculating<\/a><\/p>\n

Your office burned down over the weekend.  We\u2019re sorry to be the bearers of bad news, but it happened. What will your business do now? How fast can your IT infrastructure be back up and running? What data will it need to recover with the highest priority?<\/p>\n

These are the questions that will inevitably arise when hammering out a Disaster Recovery<\/a> plan.  In the industry, we call these questions the Recovery Time Objective (RTO) and Recovery Point Objective (RPO).  But how do you determine the ideal RTO\/RPO for your business?<\/p>\n

<\/p>\n

In this article, we\u2019re going to explain the concepts of RTO\/RPO and how you can apply them to disaster-proofing your business\u2019s IT infrastructure. That way, when you get the news that your systems and data are smoldering ashes (or less melodramatically, that your server has crashed), your first question won\u2019t be: \u201cwhat do we do now?\u201d<\/p>\n

Recovery Time Objective<\/strong><\/h2>\n

\"RTO\/RPO<\/p>\n

Your RTO refers to how long your business can afford to have its vital systems and data offline before it really starts affecting your bottom line.  In even simpler terms, it means: how quickly do you need to recover?<\/p>\n

When determining an acceptable RTO, you should be focusing on individual applications rather than entire servers.  The stopwatch starts on your RTO the instant an important application is no longer usable, and won\u2019t stop until it can be used again as normal by all users who require it.<\/p>\n

You’re on your way to understanding RTO\/RPO.<\/p>\n

Recovery Point Objective<\/strong><\/h2>\n

\"RTO\/RPO<\/p>\n

The second part of the RTO\/RPO considerations is, perhaps unsurprisingly, RPO.  Rather than the recovery time, RPO refers to the systems and applications themselves.  Determining your RPO means working out how much of the data contained within these systems and applications your company could afford to lose.<\/p>\n

This means that if you could afford to lose 2hours worth of data from your Exchange Server without it having a serious impact on your business, then your RPO would be 2 hours.<\/p>\n

While RTO will determine the speed necessary for your recovery, RPO determines how frequently you should be making backups and what kind of backups will be necessary.<\/p>\n

RPO is important for backups.  This is because it addresses the question of when and how often to back up.  If you backup at 9pm, and the next day at 10am you lose a hard drive and all of the data on it, then there could be up to 12 hours\u2019 worth of data lost \u2013 known as a \u201cbackup gap\u201d.<\/p>\n

In practice, the lost data may only be emails and word docs that staff worked on from 8am to 10am when people were at in the office. But then again, it could be a full 12 hours\u2019 worth of data from a database that was being updated all night by an important application\u2026 The key is to determine what data you would lose on each type of system if it went down, and how much of this you could afford (if any).<\/p>\n

Okay, now you understand what RTO\/RPO means, let’s put this knowledge into practice.<\/p>\n

Determining your downtime<\/strong><\/h2>\n

\"RTO\/RPO<\/p>\n

When establishing an acceptable level of downtime (for the record, we\u2019re talking about the RTO aspect of your RTO\/RPO planning here), it can be tempting to simply ask your users.  After all, they know how long they can do without their applications, right?  Well, probably not.<\/p>\n

Generally, when asking end-users you\u2019re going to get a response that\u2019s either unrealistically short (\u201cIf I can\u2019t access my emails for 30 seconds, I\u2019ll miss that sale and the world will end in fire.\u201d), or naively long (\u201cI don\u2019t even know what that application does, I\u2019m pretty sure I could go without it for a few months\u201d).  That\u2019s why, as with most things in life, you need to look at the data.<\/p>\n

The first step is to make a comprehensive list of every system and application your business uses as a part of its operations.  Then determine what role each actually plays \u2013 i.e. all functions it performs for your business and what departments\/users would be affected by its loss.<\/p>\n

Next you need to determine potential losses that could occur if the system or application were to go down \u2013 i.e. lost revenue or sales, salaries paid to idle workers, additional expenses due to lack of access, damage to company reputation etc.  Do this for every application individually, and don\u2019t forget to take into account that certain times of year will account for heavier consequences than others.<\/p>\n

Now, once you\u2019ve worked out these details is where you get to the fun part \u2013 determining exactly how long before these losses become unacceptable. Exactly how long this time will be depends on the specifics of your business, but here are some questions you should ask yourself that will factor into your ideal RTO:<\/p>\n