Sheer Terror at 10 PM

Back in the ’90s, a friend called me shortly after 10 PM with the kind of problem every IT person dreads. While expanding a server’s storage, something went wrong. After a restart produced an error, he reformatted the data partition. The data was gone. His only option was to restore from backup. 

The first tape was blank. And the second. And the third. 

The operator had been dutifully inserting a tape each night, labeling it, and putting it on the shelf. The process looked like it was working, but no one had verified the tapes. The last good backup was three months old. 

That meant roughly 50 people had to recreate three months of work. 

The technology has changed. The lesson hasn’t: a backup you haven’t verified may not be a backup at all. 

Fast-forward to 2026. We don’t worry about tape rotations anymore, but we can still get that same 10 PM panic call. Today, ransomware adds another problem: attackers know your backups are one of the biggest obstacles to getting paid. 

1. Isolate It 

If attackers compromise your production environment, they should not automatically gain the ability to destroy your backups. Keep backup infrastructure isolated from production authentication wherever possible. Separate administrative credentials, management planes, and security boundaries make it much harder for an attacker with production access to reach your recovery systems. 

2. Make It Immutable 

Use immutable storage so backup data cannot be altered or deleted during its configured retention period, even if an attacker compromises production credentials. Technologies such as Write Once, Read Many (WORM) storage can help prevent backup data from being encrypted, modified, or erased before the retention period expires. 

3. Prove You Can Restore It 

Having a backup file in the cloud is only half the battle. The real test of business continuity is whether you can restore your systems quickly, completely, and cleanly after an incident. 

Without regular recovery testing, businesses often discover silent failure points only when they need the backup most: 

• Critical applications, databases, or newly added servers are missing from the backup scope. 
• Backup jobs appear successful but contain hidden errors or corruption. 
• System files or application dependencies required for recovery aren’t protected. 
• Restores that were expected to take hours actually take days. 

A robust backup strategy includes automated verification and periodic disaster recovery drills. Recovery testing tells you whether your actual Recovery Time Objective (RTO) – how quickly you need to be operational – and your Recovery Point Objective (RPO) – how much data you can afford to lose – match what your backup system can really deliver. 

The worst time to discover your backup doesn’t work is 10 PM during an actual disaster. 

Verify it. Isolate it. Make it immutable. And most importantly, prove you can restore from it.  If you’re not sure what would happen if you had to recover tonight, reach out to our sales team before it becomes an emergency.