Why (and how) you should test your backup and recovery plan

There’s no doubt about it: ransomware and security threats are on the rise. Backing up your data is now more important than ever to protect your business in the event of an attack or security breach.

As a rule of thumb, anything that enables your business to run should be backed up. But implementing a backup solution should never be the entirety of your Business Continuity and Disaster Recovery (BCDR) plan. Rather, it should be your starting point.

If you’re not regularly checking and testing your backups, you won’t know whether you’ll be able to restore lost data until you’re in crisis mode—and with some recovery efforts taking months, you could be in for a rude awakening.

Backing up your data is a best practice. As the ISO-27001 Information Security standard recommends, “Backup copies of information, software, and system images shall be taken and tested regularly in accordance with an agreed backup policy.”

So, what do you need to know about backup and recovery testing? We’ve got you covered.

Why backup and restore efforts fail

The truth is, backup and restore efforts can fail for any number of reasons, and the time to identify those reasons should not be when your organization is already under attack. Let’s look at some common reasons for failure:

• Hardware incompatibilities or faults. Sometimes it looks like a backup was successfully written, only to have no device able to read it.
• Mismatch of encryption/decryption keys.
• Bugs in backup software that make it impossible for specific files or directories to be restored.
• The backup process is not updated to reflect changes in the IT environment.
• Malicious individuals overwriting backup rules.

The bottom line is that backups can fail, and if you’re not regularly testing them, you won’t know until it’s too late.

Ready to test? Here’s what to keep in mind

There are a few things you should consider when planning and carrying out backup and recovery tests.

Aim to carry out a full system restore. Make sure you have enough disk space or cloud storage to restore the entire backup, and compare your storage utilization with what would be required for the backup.

Spot-check your recovery test. In the event of real-life data loss, the most common recovery requests you’ll get are for one-off files and folders, contacts, or team artifacts. Make sure your backup solution’s search and filtering capabilities are working well. You can test this with metadata and keyword searches, granular artifact recovery, and recovery of various types of files. Make sure you’re also comparing the content and size of the restored files to the original files to ensure there have been no errors.

Implement offsite backups. This includes any restore applications or encryption keys. As Fabian Wosar, Emsisoft’s CTO recently told us while discussing whether or not you should pay ransom in the event of a ransomware attack, “You can back up your data locally, but you also need to mirror those backups to an outside location that you can’t easily access,” adding, “You should only be able to upload—and not delete—any data. If you can get around it, a threat actor will, too.”

Understand your network dependencies. As Wosar says, “You need to come up with a playbook and figure out the interdependencies of your services and servers so that you can rebuild everything.” This includes identifying any regulatory requirements, figuring out who needs to be informed in the event of an attack, and creating an action plan for restoring services. Figuring this out ahead of time will save you a lot of stress in the future.

The definition of IT security is constantly changing, and the stakes are being raised right along with the number and severity of threats that exist for today’s organizations. Making sure you have a plan for how to regularly test your backup and recovery efforts will go a long way in keeping your data—and sanity—intact.