Every responsible business owner knows that backups are important. Most have some form of backup system in place — an external hard drive, a cloud sync service, a server backup job running overnight. But here is the uncomfortable truth that catches businesses out time and time again: having backups is not the same as having working backups. And the only way to know whether your backups actually work is to test them.
The UK business landscape is littered with cautionary tales of companies that thought they were protected, only to discover — at the worst possible moment — that their backups were incomplete, corrupted, outdated, or simply non-functional. A 2025 study by the British Chambers of Commerce found that 34 per cent of UK businesses that experienced a major data loss event discovered their backups had failed. That is one in three businesses finding out their safety net has holes only after they have fallen.
This guide explains why backup testing is essential, how to test your backups properly, how often to test, and what to do when tests reveal problems.
Why Backups Fail
Understanding why backups fail is the first step toward understanding why testing is essential. Backup failures are not rare exceptions — they are disturbingly common, and they happen for entirely predictable reasons.
Silent failures. Many backup systems fail silently. The backup job runs every night, the log shows "completed," and everyone assumes the data is safe. But "completed" does not always mean "successful." Partial backups, permission errors, locked files, and insufficient storage can all cause a backup job to complete without actually capturing all your data. Without testing, these silent failures go undetected for months or years.
Storage exhaustion. Backup storage fills up over time. When it does, backup jobs start failing or overwriting older backups. If nobody is monitoring storage capacity, the backup system quietly stops protecting your data.
Configuration drift. Your IT environment changes over time — new servers, new applications, new file shares, new databases. If your backup configuration is not updated to include these new resources, they go unprotected. We regularly encounter businesses where their most critical application — added two years after the backup was configured — has never been backed up.
Corruption. Backup media degrades over time. Hard drives develop bad sectors. Tape cartridges degrade. Even cloud storage is not immune — if the source data is corrupted before it is backed up, the backup faithfully preserves the corruption.
Modern ransomware specifically targets backups. Attackers know that if they can encrypt or delete your backups along with your live data, you have no choice but to pay the ransom. Sophisticated ransomware strains will sit dormant on your network for weeks, waiting until they have identified and compromised your backup systems before launching the encryption attack. Testing your backups includes verifying that they are stored in a location that ransomware cannot reach — such as an immutable cloud backup with air-gapped retention.
Types of Backup Tests
Not all backup tests are created equal. There are several levels of testing, each providing different levels of assurance. A comprehensive backup testing programme should include all of them.
1. Verification Checks (Daily)
The most basic form of testing is checking that your backup jobs completed successfully. This means reviewing backup logs daily, checking for error messages, and verifying that the expected volume of data was backed up. Modern backup solutions can automate this through email alerts and dashboard monitoring, but someone needs to actually read those alerts and act on them.
2. File-Level Restore Tests (Monthly)
Once a month, pick a random selection of files and folders from your backups and restore them to a test location. Verify that the files open correctly, that the data is intact, and that the file dates and permissions are preserved. This test catches issues like silent corruption, permission problems, and encryption failures.
3. Application-Level Restore Tests (Quarterly)
Every quarter, test restoring a complete application from backup. This might mean restoring your accounting database, your CRM system, or your email server to a test environment. Verify that the application starts correctly, that the data is complete and consistent, and that users can log in and work normally. This test is critical because application restores are far more complex than file restores — they often involve databases, configuration files, and inter-system dependencies.
4. Full Disaster Recovery Tests (Annually)
Once a year, simulate a complete disaster and test your ability to restore your entire IT environment from backup. This is the ultimate test — can you rebuild your servers, restore your data, reconnect your applications, and get your business operational again? This test should involve timing the recovery to verify that you can meet your Recovery Time Objective (RTO).
How to Conduct a File-Level Restore Test
Here is a practical step-by-step process for conducting monthly file-level restore tests.
Select a random sample of files from different locations in your backup — not just one folder, but files from different servers, different shares, and different dates. Include a mix of file types: documents, spreadsheets, database files, images, and emails. Choose some files from the most recent backup and some from older backups to test retention.
Restore the selected files to a dedicated test folder — never overwrite live data during a test. Once restored, open each file and verify the content is correct and complete. Check that file metadata (dates, permissions, ownership) has been preserved. Document the results, noting any failures or issues.
If any file fails to restore correctly, investigate immediately. A single failed restore is a warning sign that other files may also be affected.
Signs of Healthy Backups
- All backup jobs complete without errors
- Backup volumes match expected data sizes
- Random file restores succeed consistently
- Application restores produce working systems
- Recovery times meet documented objectives
- Backup storage has adequate capacity and growth room
Warning Signs to Investigate
- Backup jobs complete with warnings or partial errors
- Backup volume has decreased unexpectedly
- Some files or folders fail to restore
- Restored files are corrupted or empty
- Nobody has checked backup logs in weeks
- Backup storage is above 80% capacity
Understanding RTO and RPO
Two critical metrics underpin any backup and disaster recovery strategy: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Testing your backups should verify that both can be met.
RTO is the maximum acceptable time to restore your systems after a failure. If your RTO is four hours, you need to be able to restore your critical systems and get your business operational within four hours of a disaster. Your annual DR test should time the recovery process to verify this.
RPO is the maximum acceptable amount of data loss, measured in time. If your RPO is one hour, your backup must capture data at least every hour. If your RPO is 24 hours, a nightly backup is sufficient. If your last backup was three days ago because the backup jobs have been failing unnoticed, you have already exceeded your RPO.
The 3-2-1 Backup Rule
No discussion of backup best practice is complete without mentioning the 3-2-1 rule. This simple framework has been the gold standard for backup strategy for years, and it remains as relevant as ever.
Keep at least 3 copies of your data (your live data plus two backups). Store backups on at least 2 different types of media (for example, local disk and cloud storage). Keep at least 1 copy offsite (physically separate from your main location).
In 2026, many security experts have extended this to 3-2-1-1, adding the requirement for at least one immutable copy — a backup that cannot be altered or deleted, even by an administrator. This protects against ransomware attacks that target backup systems.
| Backup Layer | Purpose | Example |
|---|---|---|
| Copy 1 (Live data) | Active business data | Your server or cloud service |
| Copy 2 (Local backup) | Fast recovery from common failures | NAS device or local backup server |
| Copy 3 (Offsite/Cloud) | Protection against site-level disasters | UK cloud backup service |
| Copy 4 (Immutable) | Ransomware protection | Immutable cloud storage with retention lock |
Documenting Your Backup Tests
Every backup test should be documented. This documentation serves multiple purposes: it provides evidence that your backup system is working, it creates a historical record of test results for trend analysis, and it supports regulatory compliance where required.
Your test documentation should record the date of the test, the type of test conducted, what was restored, whether the restore was successful, how long the restore took, any issues encountered and how they were resolved, and who conducted the test. This documentation does not need to be elaborate — a simple spreadsheet or a templated form is perfectly adequate. What matters is that it exists and is kept up to date.
For businesses subject to UK GDPR, Cyber Essentials, or industry-specific regulations, backup test documentation provides evidence of due diligence in protecting personal and business data. The ICO expects businesses to be able to demonstrate that their data protection measures — including backups — are effective, not just that they exist.
Modern backup solutions like Veeam, Datto, and Acronis offer automated backup verification features. Veeam's SureBackup, for example, automatically boots a virtual machine from a backup, runs checks to verify the operating system starts and applications respond, and records the results — all without manual intervention. While automated verification does not replace manual testing entirely, it provides a valuable additional layer of assurance between your manual test cycles.
What to Do When Tests Fail
A failed backup test is not a disaster — it is a valuable early warning. Far better to discover a backup problem during a test than during a real emergency. When a test reveals an issue, investigate the root cause immediately. Common causes include insufficient storage space, changed file permissions preventing backup access, network connectivity issues between the backup source and destination, software updates that broke backup agents, and new data sources not included in the backup configuration.
Once the cause is identified and resolved, re-run the test to confirm the fix. Then review your backup configuration holistically to check for similar issues elsewhere. A problem with one backup job often indicates systemic issues that affect other jobs too.
Building a Backup Testing Schedule
Consistency is key. A backup testing schedule should be a recurring calendar item, not something that happens when someone remembers. Here is a practical schedule suitable for most UK SMEs.
Daily: review backup job completion reports and alerts. Weekly: verify backup storage capacity and usage trends. Monthly: conduct file-level restore tests from random backup points. Quarterly: perform application-level restore tests for critical systems. Annually: execute a full disaster recovery simulation, timing the process against your RTO.
Assign responsibility for each task to a specific person or team. If you use a managed IT provider, backup monitoring and testing should be a core part of their service. Ask your provider for regular backup test reports and evidence that testing is being conducted to the agreed schedule.
When Did You Last Test Your Backups?
Cloudswitched manages backup and disaster recovery for UK businesses, including regular testing and verification. If you are not confident that your backups would work when you need them, or if you have never tested a full restore, get in touch. We will audit your current backup arrangements and ensure your data is genuinely protected.
GET IN TOUCH
CloudSwitched
Centrally located in London, Shoreditch, we offer a range of IT services and solutions to small/medium sized companies.