Testing your backups

Backups fail quietly

Backup systems tend to fail without anyone noticing. A job stops running after a software update, a new folder is never added to the backup selection, a cloud application is assumed to be backed up when it is not or the backup drive fills up and starts skipping files. Each problem is invisible until the day you need to restore something important.

That is why testing matters more than the backup software you choose. A backup that has been restored successfully in the last few months gives you real confidence. A backup that has only ever shown a green status icon is an assumption that has not yet been checked against reality.

The 3-2-1 approach

A widely used guideline is the 3-2-1 approach: keep at least three copies of important data, on at least two different types of storage, with at least one copy offsite. For example, you might keep the live data on your server, a local backup on a separate storage device for fast restores and a copy with a cloud backup provider located away from your office.

Many organizations now add a further requirement: at least one copy should be immutable or offline, meaning it cannot be changed or deleted for a set period even by an administrator. This protects against ransomware that targets backups, which has become a common tactic, and it is a control many cyber insurers ask about directly.

Do not forget cloud data

Moving to Microsoft 365, Google Workspace or another cloud platform does not remove the need for backups. These providers keep their services running, but recovering from accidental deletion, a malicious insider, a compromised account or ransomware that syncs encrypted files to the cloud is generally your responsibility. Built-in retention features help, but they have limits.

A dedicated backup of your cloud email, OneDrive, SharePoint and Teams data gives you independent copies you control. Check line-of-business cloud applications too, and ask each vendor what backups they keep, how long they keep them and whether you can request a restore of your own data. Include these in your restore testing.

How to test

Testing does not need to be complicated. The goal is to prove, on a regular schedule, that you can get back what you would need after a real incident, within the time the business can tolerate. Record each test, including what was restored, how long it took and any problems found, so you have evidence for insurers and auditors.

Vary the tests over the year so that different systems and scenarios are covered, rather than restoring the same small file every time. Include at least one test that assumes your office is unavailable, so you know the restore works from offsite copies alone. Share the results with leadership so the business understands its real recovery capability. The checklist below is a reasonable starting point.

• Restore individual files and mailboxes every month or quarter
• Restore a full server or application at least once a year
• Check that restored data opens and is complete
• Measure how long the restore takes
• Confirm backup alerts reach someone who acts on them

Protect and review

Backups contain all of your sensitive information, so they need the same protection as your live systems. Use separate credentials for backup systems, require multi-factor authentication, encrypt backup data and limit who can delete or change backup settings. Attackers who gain administrator access often try to delete backups before launching ransomware.

Review your backup scope whenever you add a new system, application or location. Ask your IT provider for a regular report showing what is backed up, how often, where copies are stored, how long they are kept and the results of the latest restore test. Retention periods should also align with your record-keeping and privacy obligations.