How Often Should You Test Your Backups? (And How to Do It)

Here's a question that keeps IT professionals up at night: if your server went down right now, could you actually recover your data? Not "do you have backups" — but can you prove they work?

The uncomfortable truth is that most small businesses cannot. A study by Unitrends found that 34% of businesses never test their backups, and of those that do test, 77% have discovered failures. Having backups that don't restore is the same as having no backups at all.

Why Backups Fail (More Often Than You'd Think)

Backup jobs can fail silently for a surprising number of reasons:

• Corrupted backup files: The backup completed successfully according to the software, but the data files are corrupted and can't be restored
• Changed file paths: Someone moved a folder or reorganised a drive, and the backup job is now backing up an empty directory
• Exceeded storage: The backup destination ran out of space, and old backups were automatically deleted to make room — but the new backup then failed partway through
• Application-aware issues: File-level backups don't always capture databases correctly. SQL databases, Exchange, and some industry applications need application-aware backups that flush transactions before copying
• Encryption key loss: Backups are encrypted (as they should be), but when you need to restore, nobody can find the encryption key or password
• Ransomware encryption: If your backup storage is network-accessible, ransomware can encrypt your backups alongside your production data

How Often Should You Test?

The NCSC and most compliance frameworks recommend regular backup testing, but what does "regular" mean in practice? Here's what we recommend based on business size and risk:

A Simple Monthly Testing Process

You don't need expensive tools or a large IT team to test your backups. Here's a practical monthly process that any business can follow:

Step 1: Check Your Backup Reports

Log into your backup software (Veeam, Acronis, Datto, Windows Server Backup, or whatever you use) and review the last 30 days of backup jobs. Look for:

• Any failed or partially completed jobs
• Warnings or errors that were ignored
• Unusual changes in backup size (a sudden drop might mean data isn't being captured)
• Gaps — days where no backup ran

Step 2: Perform a Test Restore

Select 5-10 files from different locations and time periods. Restore them to a temporary folder (never overwrite production data during a test). Verify each file opens correctly in its native application — a Word document should open in Word, a database backup should import into the database engine.

Step 3: Test an Application Restore

Once a quarter, go further and restore a full application. If you have a test server (or can spin up a virtual machine), restore your most critical application — whether that's your accounting software, CRM, or practice management system. Verify that the application loads, data is present, and you can perform basic operations.

Step 4: Document the Results

Keep a simple log: date, what was tested, result (pass/fail), any issues found, and actions taken. This documentation proves due diligence for audits, insurance claims, and compliance requirements. It also creates accountability — if nobody's documenting tests, tests aren't happening.

The 3-2-1 Backup Rule

If you take nothing else from this article, implement the 3-2-1 rule:

• 3 copies of your data (production data plus two backups)
• 2 different types of media (e.g., local NAS/server plus cloud storage)
• 1 copy offsite (cloud backup, or a physically separate location)

This protects you against hardware failure (local backup), fire/flood/theft (offsite copy), and ransomware (air-gapped or immutable backup). No single event should be able to destroy all three copies of your data.

Don't Forget Microsoft 365

A common misconception is that Microsoft backs up your data in Microsoft 365. They don't — at least, not in the way most businesses expect. Microsoft's native retention policies protect against infrastructure failures on their end, but they don't protect you against:

• Accidental deletion beyond the recycle bin retention period (93 days for SharePoint, 30 days for Exchange)
• Malicious deletion by a compromised account or disgruntled employee
• Ransomware encrypting OneDrive files (version history can help but has limits)
• Data needed for legal holds or compliance beyond Microsoft's retention windows

We recommend a dedicated Microsoft 365 backup solution such as Veeam Backup for Microsoft 365, Acronis, or Datto SaaS Protection. These tools back up Exchange, OneDrive, SharePoint, and Teams data to storage you control, with granular restore capabilities.

What Happens When You Don't Test

We've seen businesses discover their backup failures at the worst possible moment — during an actual disaster. Common scenarios:

• A law firm's server failed. Their backup drive had been full for 3 months — the nightly backup emails were going to an inbox nobody checked
• An accounting firm's ransomware recovery took 5 days instead of the expected 4 hours because their backup software version was incompatible with the new hardware they'd sourced
• A construction company's cloud backup had been running for 2 years, but nobody had the encryption passphrase. The person who set it up had left the company

All of these situations were preventable with regular testing.