One of the most widespread misconceptions in IT security is that a backup is good because it appears to be running. The truth is that many backups fail precisely when needed, because they have never been tested. A backup you have never restored from is really just a hope.

Why backups fail in practice

There are several reasons why an apparently functioning backup may not be usable when it really counts:

  • Silent failures: the backup job reports success, but files are corrupt or incomplete
  • Incorrect scope: critical folders were never added to the backup configuration
  • Encryption without key: the backup is encrypted, but the encryption key is stored in the same place as the data
  • Outdated software: the recovery tool cannot read a newer backup format
  • Ransomware in the backup: malware ends up included in the encrypted backup files because the backup is accessible from the infected network

The 3-2-1 rule is the minimum: You should always have 3 copies of your data, on 2 different media types, of which 1 copy is offsite, preferably in another data center or a cloud solution isolated from your primary network. The rule is simple, but surprisingly few companies follow it fully.

A simple 5-step recovery test

You do not need a crisis scenario to test your backup. Plan a short test quarterly. It typically takes less than an hour and gives you concrete assurance about what you actually have to fall back on.

  1. Choose a specific file or folder, not everything at once. Take a document or a database that is business-critical, and delete a copy locally.
  2. Open your backup console and locate the file. Can you even navigate to the correct date and version? Many discover here that the interface is not what they expected.
  3. Restore to an alternate location. Never restore directly to the original folder during a test. Use a temporary location so you can compare.
  4. Open and verify the contents. Is the file intact? Is it the right version? Can you open it without errors?
  5. Document the result. Write down when you tested, which file, which date in the backup, and whether it succeeded. It is your evidence and your starting point next time.

Warning signs of an unreliable backup

Watch for these signs indicating that your backup is not reliable:

  • Backup jobs that have not run in the last 24–48 hours without any alarm
  • Backup files that never grow in size, which may indicate that nothing is actually being copied
  • Backup accessible from the same user account as production data: a ransomware attacker can reach both
  • No separate notification on failure: you only know it works if you actively check it
  • No offsite copy: fire, water damage, or theft affects both backup and original simultaneously

A functioning backup is not something you set up once and forget. It is an ongoing practice. Test it. Document it. And ensure that the person who needs to use it in a crisis actually knows how, rather than having to figure it out in a panic.