If your business deals with any significant amount of data, chances are an SQL Server is a vital part of your IT environment. There’s no doubt that you’re backing this server up regularly, because in a contemporary business environment you can’t afford to risk losing those databases. But the real question is, have you thought about recovery?
RPO (Recovery Point Objective) refers to how much data your company can afford to lose during a recovery. It’s what dictates the kinds of backups you perform and how regularly. The key point to keep in mind is that, as with all elements of your backup strategy, your RPO for SQL Servers needs to be both adequate and realistic. So how do you know if yours is?
Well, let’s find out.
Determining RPO for SQL Servers
Before we start, it’s worth making sure everyone’s clear on exactly what RPO means and how you should go about calculating it. If you’re not 100% on either of those things, take a couple of minutes to read this article first. Don’t worry, we’ll be waiting right here for you.
And we’re back. Let’s get into why knowing your RPO for SQL Servers is important, and how you should go about determining it.
The thing about SQL Servers that often differentiates them from some other server applications is the frequency with which their data is updated. Because databases are in a state of near-continuous change you may need to protect this data more regularly. Whereas a daily backup (giving you an RPO of 24 hours) might be fine for a file server, an SQL Server can contain a great deal of critical data that has been updated during this time.
That means a general rule-of-thumb for determining your RPO for an SQL Server is the lower the better.
In order to determine the ideal RPO for your company’s SQL Servers, you need to first identify how much of your critical database data changes and how much new data is added – i.e. data that would cause harmful impact (be it financial, regulatory or otherwise) if your company lost it.
Reducing your RPO for SQL Servers with BackupAssist
So you’ve identified your RPO, and it’s lower than what you’re currently achieving. Well, the good news is you can use BackupAssist’s SQL Protection Add-on to remedy this.
While the base license of BackupAssist can protect full-server backups and restores, this can limit your RPO to however frequently your backup window makes it practical to perform one – generally no more than twice per day. This is absolutely fine if you’ve determined that your databases aren’t being populated with mission critical data within that period. And for many users, this will be the case and the Base License of BackupAssist will suit their needs perfectly.
But what if you’ve determined you’ll need to protect data hourly? What if there’s vital data being updated every 10 minutes?
One of the main ways the SQL Protection Add-on improves your RPO for SQL Servers is by performing near-continuous transaction level backups. What this essentially means, is that any changes to the SQL Server databases (transactions) will be logged in regular intervals (as frequently as every 5 minutes, giving you the ability to restore the database to a point-in-time.
That means you can still run your scheduled backup once per day, but within that backup will be the ability to restore to a point-in-time within a 5 minute period any time since the previous day’s backup. Therefore, instead of an RPO of 24 hours, you now have an RPO that can be as little as 5 minutes, without changing the frequency with which you perform your SQL Server backup.
Want some more in-depth information on the BackupAssist SQL Protection Add-on? Check out this detailed whitepaper.
What’s the RPO for your SQL Servers?
We’d love to hear! Leave a comment, tweet @BackupAssist or post to Facebook.
Share this article, and let’s better protect databases everywhere.
