Solutions & Services
Whether you’re looking to deploy Apple in your business, increase digital collaboration in your workplace or improve your IT infrastructure, our solutions have got you covered. They’re delivered by experts who’ve worked in your field and are passionate about helping your business meet its objectives with technology. Read more
About
We’re a bit different from your average IT reseller. Throughout our nearly 30-year history, we’ve developed a proud company culture rooted in delivering great customer service and treating people with the respect they deserve. Find out more about what makes us tick and how you could fit in with the team. Read more
There's nothing this blog likes better than jargon-busting, and today we've got two key backup acronyms in our sights: RPO and RTO.
RPO stands for recovery point objective. It refers to the last point in time you can afford to restore to. So for example, if one of your systems relies on a static database, the RPO for that database could be hours or even days – you can work as well from last week's data as from yesterday's. If you run an online store, though, your RPO will be to the last transaction, which could be seconds ago.
RTO stands for recovery time objective. This is the amount of time your key systems can go down for without your business being adversely affected. For example, if your server crashed on Thursday and you could afford for it to stay offline until the end of Friday without losing any business, your RTO would be a day. If you can't afford to ever have your systems go offline, then your RTO is zero.
RPO dictates how redundant your storage, infrastructure and backup need to be. The lower your RPO, the more redundancy you need to build into your organisation.
Your RTO dictates the type of backup and data replication that you need. For example, restoring from a tape archive can take days, so if your RTO is less than that you may want to use disks for archive storage instead, and make sure you have a good offsite data replication solution you can work from.
Not quite. Data replication is a mirror copy of your data that you can access instantly in the event that your primary system goes down. Data stored there is in a format that end users can use immediately. One customer of ours, for example, has a copy of their main server hosted in the cloud, and if their internal network goes down, key members of staff can just log into the cloud version of the server and keep working. Replicating your data is expensive as you need twice as much storage, but massively reduces the time it takes you to get back up and running.
A backup is a copy of your data that is unconnected to your live system, is probably kept in a format that your end users can't access immediately, and needs to be restored before it can be accessed. There is no instant access to a backup copy.
Well, your RPO is simply the amount of data you can afford to lose and still function as a business, so you're going to to need to sit down with a copy of your backup schedule and make sure that it gives you access to the data that you need. One thing to bear in mind is that where your backups are is almost as important as when they were done – if you make backups every day but only take them offsite at the end of the week, a flood would destroy a week's worth of backups, not a day's worth. If keeping your RPO down in a priority, it's better to invest in more media and move your backups offsite every day (you might consider using the cloud rather than physical drives to control the cost of this).
Your RTO is based on a range of factors, including: how quickly downtime will lead to you losing money; how quickly downtime will cause a loss of customer faith and see you lose customers to rivals; which business practices are dependent on which systems (the RTO for systems with a lot of dependants is less than that of systems with few dependants); how critical those dependants are (the RTO for critical dependants is lower that that of non-critical ones).
This is an increasingly common question. Rich media files can be huge, which means you can end up with multi-terabyte file and email servers to back up every day, which can actually take longer than a day to do. This backup deficit is, obviously, deeply bad from a data recovery point of view.
What you want to do is take a tiered approach. Get everything you're keeping 'just because' or which isn't used regularly over to an offsite archive, and back this up as infrequently as is safe (every month, for example). Then, you'll only need to do daily/hourly backups on current files and live projects, which will be far faster and be less likely to have a negative impact on day to day user experience.
You can also use a tiered system to reduce overall costs. Rather than keeping everything on the most redundant possible storage, identify your critical systems, medium priority systems and low priority systems, and build in appropriate levels of redundancy and data protection for each.
Want to know more about ensuring you can meet your RTO and RPO? Give us a call on 03332 409 306 or email solutions@Jigsaw24.com. For all the latest news and reviews, follow us on Twitter @WeAreJigsaw24 and ‘like’ us on Facebook.