Why Untested Backups Fail (and How to Test)

Untested backups fail because a backup job that reports "success" only proves that something was written, not that you can restore it, that it contains the right data, or that you can do it fast enough to keep your business running. Backups break quietly: jobs skip files, credentials expire, storage fills, encryption keys go missing, and ransomware deletes the copies it can reach. The only dependable answer is to restore from your backups on a schedule, record what happened and fix what you find, before a real incident does it for you.

What "a backup" does not prove

Many businesses believe they are protected because a green tick appears in a dashboard. A tick tells you the job ran. It does not tell you:

• That the right data is included. New servers, new cloud apps and new folders are often missed.
• That the data is readable and not corrupted.
• That you hold the passwords or encryption keys needed to open it.
• That the restore process works on a clean system, not just on the machine that created the backup.
• That you can restore within the time your business can tolerate.
• That the copy is safe from the same incident that damaged the original.

Why backups fail in practice

Silent job failures and drift

Jobs that worked at setup may later fail after a password change, a full disk, a network change or an update. If alerts go to an unread mailbox, the failure goes unnoticed for months. Environments also change. A new database or a new shared drive is created, nobody adds it to the backup scope, and the gap sits there until the day you need it.

Incomplete coverage

Backups often cover files but not the pieces needed to rebuild a working system: configuration, databases in a consistent state, mail, application settings, user accounts and licences. Restoring files onto nothing does not give you a running service.

Sync mistaken for backup

File-sync tools mirror whatever happens on one side to the other. If someone deletes a folder or ransomware encrypts files, the damage can propagate. Version history can help within its limits, but it is not the same as an independent backup with retention you control.

Backups that share the fate of the original

A backup stored on the same server, the same network share or reachable with the same administrator account can be destroyed by the same event: fire, theft, a hardware failure or ransomware. Attackers commonly look for backup systems and try to delete them first. At least one copy should be separate, access-controlled and, where possible, immutable or offline.

Missing keys, credentials and documentation

Encrypted backups are only useful if you have the key. Restore procedures that live in one person's memory fail when that person is on holiday or has left. Store recovery keys and procedures securely, and somewhere you can reach if your main systems are down.

Restores that are too slow

Restoring large volumes over a modest internet connection can take far longer than people assume. If the business cannot function for that long, the backup design needs to change, for example with local copies for fast recovery and off-site copies for disaster protection.

Two numbers to agree first: RPO and RTO

Term	Plain meaning	Question to ask
RPO (recovery point objective)	How much recent data you can afford to lose	If we restored last night's copy, what would we lose today and could we live with that?
RTO (recovery time objective)	How long you can be without the system	How long can this system be down before it seriously hurts the business?

Agree these per system with the people who rely on it, not only the IT team. Your accounting system may tolerate a day of downtime, while the system taking customer orders may not. These targets set how frequently you back up, where copies are kept and how recovery is designed. They also give you pass or fail criteria for tests.

The 3-2-1 guideline, and a modern addition

• 3 copies of your data (the live data plus two backups).
• 2 different types of storage, so one failure does not take both.
• 1 copy off-site or in a separate environment.
• Where possible, one copy that is immutable (cannot be changed or deleted for a set period) or offline, to resist ransomware.

It is a guideline, not a guarantee. Your own recovery objectives and risks decide how far to go.

What to test, from simple to thorough

Level 1: file restore test (monthly or quarterly)

Pick a handful of files at random, including some from different systems and dates, and restore them to a separate location. Open them and check they are intact. Record how long it took.

Level 2: application or database restore (quarterly or twice a year)

Restore a database or an application to a test environment and check that it starts, that data is complete and that a user can log in and perform a normal task.

Level 3: full system recovery exercise (annually, and after major change)

Simulate losing a server or an entire environment. Rebuild from backups in a clean setting, time every step and note the missing documents, credentials or dependencies you stumbled over. Include a person who did not set up the original backup, to prove the procedure is usable by others.

A restore test you can run this week

1. Choose a scenario. For example: "A staff member deleted the finance folder yesterday."
2. Select data and a date. Pick a real folder and a recovery point from a few days back.
3. Restore to a separate location, never over live data.
4. Verify. Open files, check totals in a spreadsheet or a few records in a database, confirm permissions.
5. Time it, from the moment the request was made to the moment the data was usable.
6. Compare with your RTO and RPO. Did it meet them?
7. Record the result, including failures and surprises, in a simple log.
8. Fix and retest anything that failed.

A simple test log format

Date	System	What was restored	Time taken	Result	Action
Example date	File server	Finance folder, three days old	Recorded here	Pass or fail	Fix named, owner, date

The row above shows the format only. Fill it in with your own results.

Backup and recovery checklist

• Every critical system and data source is listed, with an owner.
• Recovery objectives (RPO and RTO) are agreed for each.
• Backups run automatically, and failure alerts go to a person who acts on them.
• At least one copy is separate from the main environment and protected from deletion by compromised accounts.
• Backups are encrypted, and recovery keys are stored securely and separately.
• Backup scope is reviewed whenever systems are added or changed.
• Restores are tested and logged on a schedule.
• Written recovery steps exist, someone other than the author has followed them, and they are accessible when systems are down.
• Cloud services and software-as-a-service data are included, since the provider may not back up your data the way you assume. Check the provider's terms.
• Retention covers how far back you might need to go, including problems noticed late.

Ransomware and backups

Ransomware changes the backup conversation, because attackers deliberately target backups. Keep backup administration separate from everyday administrator accounts, use MFA, restrict network access to backup storage, and keep an immutable or offline copy. Test that you can restore from it. Backups are one part of resilience alongside the measures in our IT security audit checklist for small businesses.

Common mistakes

• Trusting the green tick without a restore.
• Testing only on the original machine. Prove you can recover onto clean systems.
• Backing up everything the same way, regardless of how important it is.
• Ignoring SaaS data such as email, collaboration tools and your CRM.
• No retention thought. A problem discovered weeks later may be in every recent backup.
• Keeping recovery keys only in the system that is down.
• Not updating backups after changes to servers, applications or cloud services.
• One person who knows how to restore.

Who should own this

Backup and recovery need a named owner who reports results to the business, plus a regular slot in the calendar. Whether that person is in-house or at a provider, ask for the test log, not just reassurance. If you are evaluating outside help, our guide to what managed IT services include lists the questions to ask about backup handling.

Making it routine

CloudWiss provides managed IT and support services covering system maintenance, security audits and ongoing infrastructure management, which can include keeping backups and recovery procedures under regular review. If you are unsure whether your current backups would hold up, a restore test is the quickest way to find out, and we can help you plan one.