August 2, 2017

When you invest in a great new BDR solution, you can get a lot of guidance from the vendor’s onboarding and support team. At Quorum, we work with new customers every step of the way to ensure their every question is answered and their every move is confident. But there are some questions we (or any vendor) can’t answer – because they’re too dependent on the nuances of your infrastructure.

One of those questions: deciding on the frequency of your snapshots. Functioning as an image of your system at a particular point in time, snapshots can help you improve your Recovery Point Objective (RPO) and accelerate recovery. Teams often wonder which assets deserve which frequency and how to stagger snapshots in a way that ensures data stays protected without wasting resources.

There are no hard and fast rules. Only you know your own data recovery needs. But here are a few things to consider.

• Identify your priorities. What are the most critical data and servers? Which sees the heaviest and fastest flow of data, as opposed to servers with a more sluggish data change rate? Once you know where you can’t afford to lose data and where you can, you’ll be able to allocate your resources appropriately. For many teams, their Exchange server and any servers handling sales transactions are a top priority.
• Look at your retention policy and your disaster recovery plan. What are your most likely risks? What are your RTO and RPO? All of these elements will have a strong influence on your snapshot and testing schedule. Consider too the order in which you intend to recover your apps and account for any app dependencies. Restoring multiple servers is a sequential process, so be sure your snapshot schedule reflects that.
• Size properly. Be honest about what you need. At Quorum, we sometimes come across teams who tell us one thing in terms of their storage capacity and expected snapshotting frequency. They get an appliance with a certain amount of capacity that can accommodate those needs. Then they try to quadruple their backups and quickly run out of space while slowing their system down. Assess your needs accurately from the start.
• Pay attention to backup activity reports. Another common mistake we see concerns teams who ignore the reports on their backup health and activity. When disaster hits, they turn to their backups – only to discover they haven’t been functioning for a week.

Quorum uses onQ for backup and recovery: How We Do It

To explain how this plays out for us, at Quorum we have a 12-hour window of exposure for our Exchange server. In other words, we’re comfortable losing 12 hours of email. And because backing up can slow down systems, we also have our snapshots scheduled for 6 p.m. and 6 a.m. so they don’t have a significant impact on productivity.

You might be wondering - why don’t we make it 4 hours? Well, that would require more storage and resources, and would have a stronger impact on our daily schedule. We decided it’s not worth it. This is the ultimate question your team will need to grapple with: how much you want to invest to protect each resource – and what level of exposure your leadership is comfortable with. Timing the frequency of your snapshots is essentially a balancing act. Weigh your need to protect your data against your need for resources, and you’ll eventually arrive at the right schedule for your needs.