We all know how critical data backup is to your organization’s longevity (at least, you will if you’ve been paying attention to any of our other articles on the subject).
In fact, many organizations are willing to invest thousands of dollars each month in a comprehensive backup and disaster recovery solution just in case something were to happen to their equipment or office building.
The trouble with backup solutions, though, is that they run in the background; while you can tell immediately that your desktop isn’t working properly, how are you to know if a copy of your data was actually sent off-site to that datacenter across the country?
We can’t count the number of times that we’ve been speaking with a prospective client and they honestly have no idea whether or not the mysterious solution their IT team implemented is doing what it’s supposed to be doing (i.e. protecting your entire company’s knowledgebase).
This is why we want to address how you can be sure that your backup solution is working—it really can mean the difference between recovering smoothly from a disaster, or losing your business altogether.
How to be sure your backups are working
There is only one way to be absolutely sure if your data backup solution is working: TEST IT.
Test your files and email restores. Test your server virtualization. Test your network virtualization.
No matter how many verifications, confirmations, or alerts you receive from your technology, the only way you’ll ever know if you can recover is if you stage a disaster and try to get your information back. Because here’s the thing: your backups can be as “successful” as possible, but if there’s a problem with your server that you don’t know about, you could be backing up corruption. You cannot restore from this.
How often should you run these tests? That depends on how important your data is to you, and how available your IT team is to help you with the tests. We would recommend quarterly tests for industries with very low tolerance for downtime or data loss (law firms, for example). At minimum, we suggest testing once a year.
Yes, it’s a process, and yes, it will take some dedicated time from your team. But when the stakes are this high, can you really afford not to?