By Brian Oppermann, Senior Systems Engineer
In an earlier blog series, I asked an important question – Are you confident in your backup solution? – and then I offered eight data protection pointers that, when addressed, will help you to honestly answer “yes” to that question. One of those points – that it’s important to know how you will validate your backup – comprised only a small part of that article, but it really deserves a lot more real estate than a single bullet in a list.
As you can clearly see from Part 1 of this blog series, testing your backups is something that can draw a line in the sand for your business following a disaster that results in the loss of your business-critical data. So many people adhere to the “if it’s not broken, don’t fix it” method of managing their IT that they don’t even realize something might actually be broken. And that leads me to a whole new set of six questions that I hope will give you reason to consider the importance of backing up – and the importance of spending the time and dedicating the IT resources to thoroughly test those backups regularly.
- Why is it important to test backups? It’s critical to test your backups to ensure they are functional and that your data is restorable. Additionally, it gives you time to perfect your organization’s restore processes when you are not in the midst of a time-critical crisis. By testing your backups, you can correct any misunderstandings in the process so there won’t be long delays when the crisis is real and the business is actually waiting for the data to be available. When a business is waiting for data to be restored, every second of time that passes is money lost.
- What can happen if you don’t periodically test your backups? It is possible for backup data to be corrupted and to become unrestorable, something you may not know has happened if you don’t periodically test your backups. This will become a much more significant problem if the first time you discover this is when you absolutely must restore data that has been lost due to a failure of your systems. Additionally, without performing regular restores, you won’t have the restoration process down to a science. Learning under pressure will take longer and cost your company precious time and money.
- What tasks should you include in your backup testing strategy? First, you need to outline the kinds of restores you may need to perform – and you need to test each of those regularly. A few kinds of restores organizations commonly test include:
- File Level
- Bare Metal Recovery (restoring a system from scratch)
- Database Restores
- Mailbox Restores
- Application Testing
- Disaster Recovery Testing
In addition to testing each of the various types of restores, organizations should also consider performing a disaster recovery (DR) test at least once per year. In a DR test, you will want to practice recovering all your organization’s business-critical apps and supporting systems (i.e., Active Directory, DNS, mail, databases, etc.), and you will need your end users to test the apps you’ve restored to ensure that the data is valid and that your IT team has the process down. The worst thing that can happen to a company is to experience a disaster and then discover that either their backup data is unrecoverable or that it will take days – or even weeks – to work through an untested process.
- When and how often should you conduct a backup test? The various restore tests I mentioned above should be done at least annually. Remember, though, that if you find yourself in the situation of needing to do a restore, that in itself would be acceptable as a test. The most often requested restore is file level, and the DR test is the most time consuming and difficult to coordinate since it requires users from multiple areas as well as IT to participate.
- What are the biggest mistakes organizations make when creating their backup testing plan? Failing to test the plan. The single biggest mistake I’ve seen organizations make is underestimating the time it takes to complete a restore because their procedure was not fully tested before the crisis took place. Additionally, speaking specifically of a DR test, I have seen organizations take shortcuts with data availability that simply would not be possible in the event of an actual DR emergency. It’s also important to remember that having a failed test is ok. It shows you what you need to fix to be successful in the event of a real crisis. While a successful test is ideal, cheating on the test with workarounds is never a good idea because it simply won’t give you the assurance you need that your backup works the way you intended it to work.
- Are your recovery objectives attainable? Clearly, simply backing data up is not enough. You also need to thoroughly understand your recovery objectives. Without knowing how to recover as well as how long it will take to recover, you will be unable to set your recovery point objectives (RPOs) and recovery time objectives (RTOs) realistically, and you won’t know if you have the right tools in place. If your RPO is one day’s worth of data and your RTO is 12 hours, can your existing toolset meet that need? Throw out everything any tool’s marketing brochure tells you because, without testing it yourself, you simply won’t know how the tool reacts in your environment.
Now, ask yourself, “How critical is business continuity to the future of my company?” Disasters happen all the time, and they happen everywhere on the globe. Being prepared and testing your recovery plan will give your IT team the tools and knowledge to ensure that the least amount goes wrong when it does.
Want to learn more? Explore SRC Technologies’ data protection and recovery solutions, then download a checklist and datasheet. Read a two-part blog series about backup and recovery: Part 1: Answer Truthfully: Are You Confident in Your Backup Solution? and Part 2: Eight BC/DR Questions Every SMB Needs to Answer. Next, explore SRC’s managed backup services powered by Datto. Want a FREE consultation to get you started? Sign up for one here or give us a call at 920-965-8060 to see if a backup solution from SRC might be right for your organization.