A backup that hasn't been tested is just a hope. Discover the common reasons backups fail and why regular testing is essential for business continuity.
Every business owner believes they have a backup. Very few have tested whether that backup actually works. This distinction matters enormously — and the moment it matters most is the worst possible time to find out the answer.
The ACSC reports that backup failure is one of the most common reasons ransomware attacks result in extended business outages. Not because businesses did not have backups, but because when they went to restore, the backups were incomplete, corrupted, outdated, or simply had never been tested.
A backup that has not been tested is not a backup — it is a hope.
Why Backups Fail
1. Silent Failures Over Time
Backup jobs fail silently. A misconfiguration, a permissions change, a full storage volume, a network interruption — any of these can cause a backup job to stop running without anyone noticing, because nobody is monitoring the backup logs.
Businesses discover their last successful backup was six months ago only when they try to restore. By then, the data gap is catastrophic.
The fix: Monitor backup job completion daily. Every failed backup job should generate an alert that goes to someone who acts on it.
2. Incomplete Backups
Many backup configurations back up files but not the things you actually need to restore a system: application configuration, database transaction logs, system state data, or cloud data that is not explicitly included in the backup scope.
A common example: backing up the file server but not the cloud-hosted database that drives a line-of-business application. When the server fails, the files restore fine — but the application data from the database is gone.
The fix: Map every critical business system and confirm each component is in scope for backup. Test restoration of the application, not just the files.
3. Backup Encryption and Access Issues
Encrypted backups require decryption keys. If those keys are stored only on the system being recovered, or in a password manager accessible only through the compromised system, restoration is impossible.
Similarly, cloud backup accounts with MFA — where the MFA device is the phone of the IT person who has left the company — create access barriers at exactly the wrong moment.
The fix: Document backup access credentials and store them in a secure, accessible location that does not depend on the systems being recovered. Succession planning for backup access is not optional.
4. Ransomware Encrypting the Backups
Modern ransomware specifically targets backup systems before deploying the encryption payload. If your backup destination is accessible from the network (mapped drive, NAS on the same network, cloud backup with credentials stored on a domain-joined machine), ransomware can encrypt your backups along with your production data.
The fix: Air-gapped or immutable backups — backup destinations that cannot be modified or deleted from the production network. Cloud backup with immutability settings enabled prevents ransomware from destroying the backup copy.
5. Recovery Time vs Recovery Time Objective
Even a perfectly intact backup is useless if restoring from it takes longer than your business can tolerate. Restoring a 5TB server from cloud backup over a standard NBN connection might take 48-72 hours. If your business cannot function for 72 hours, this is not an acceptable backup solution regardless of its integrity.
The fix: Define your RTO (Recovery Time Objective — maximum acceptable downtime) and RPO (Recovery Point Objective — maximum acceptable data loss) before choosing a backup solution. Verify that your backup solution can meet these targets.
What a Proper Backup Test Looks Like
A backup test is not “confirming the backup job completed successfully”. That only tells you data was written to the backup destination. It does not tell you whether it can be read back.
A genuine backup test:
-
File-level restore test: Restore a sample of individual files from the backup to a test location. Confirm they open correctly and are not corrupted.
-
Application restore test: For database-backed applications, restore the application to a test environment and confirm it functions correctly with the restored data.
-
Full system restore test (annually): For critical servers, perform a full bare-metal restore to test hardware or a VM. Confirm the system boots, applications run, and data is intact. Time the restoration process to validate against your RTO.
-
Ransomware recovery drill: Simulate a ransomware scenario — assume production systems and local backups are compromised. Recover exclusively from your offsite/immutable backup copy. How long does it take?
Backup Testing Frequency
| Test Type | Recommended Frequency |
|---|---|
| Backup job completion monitoring | Daily (automated alert) |
| File-level restore test | Monthly |
| Application restore test | Quarterly |
| Full system restore test | Annually |
| Ransomware recovery drill | Annually |
The 3-2-1 Backup Rule Revisited
The 3-2-1 rule (3 copies, 2 media types, 1 offsite) remains sound but needs updating for the ransomware era:
3-2-1-1-0: 3 copies, 2 media types, 1 offsite, 1 immutable (cannot be overwritten or deleted), 0 errors (all backup jobs verified clean).
The immutable copy is the critical addition — it is the copy ransomware cannot touch.
CX IT Services manages backup solutions, monitors backup job completion, and conducts quarterly restore tests for Melbourne business clients. Book a Right Fit Call to discuss whether your current backup arrangement would survive a ransomware attack.
