"Do you have backups?" is one of the first questions we ask when assessing a legacy system. Almost everyone says yes. The follow-up question is the one that changes the mood: "When did you last restore one?"

Long silence, usually. And that silence is the real risk—because an untested backup is a hypothesis, not a safety net. The business believes it's protected, budgets as if it's protected, and takes on risk accordingly. Whether it's actually protected only gets tested on the worst day.

The Ways Backups Silently Fail

Backups rarely fail loudly. They fail in ways nobody notices for months:

The job has been failing since a password changed

A service account password rotated, the scheduled job started failing, the failure email went to a developer who left two years ago. The backup folder still has files in it—from 2024.

It's backing up the wrong thing

The database is backed up, but not the file uploads. Or the application server is imaged, but the database lives on a different machine that nobody added to the schedule. A partial backup restores into a system that doesn't work.

Transaction log backups were never configured

A nightly full backup in a SQL Server database running in full recovery mode means two things: you can lose up to a day of transactions, and your log file has been growing since the day it was set up. Both are usually discovered at the same unpleasant moment.

The backup sits on the same machine as the system

Backups on the same server, or the same physical site, protect you against one type of failure—accidental deletion—and no others. Hardware failure, ransomware, fire and theft take the original and the copy together.

The files are there but can't be read

Corrupt archives, backups from a database version you no longer run, an encrypted file whose key nobody has, or a backup format that needs software licensed to a former employee. The bytes exist. They just aren't usable.

What a Real Restore Test Looks Like

A restore test isn't checking that the file exists. It's proving that a working system can be rebuilt from what you have, by someone who will be available when it matters.

1. Pick a recent backup at random. Not a freshly made one—something from the normal schedule, so you're testing the real process.
2. Restore it to separate hardware or a VM. Never over your live system. The point is to prove the backup works, not to risk what's currently running.
3. Bring the full system up, not just the database. Application, database, configuration, file storage, integrations pointed at test endpoints.
4. Log in and use it. Open a recent record, run a report, create a transaction. A database that restores but an application that won't start is still an outage.
5. Check how much data you lost. Compare the newest record in the restored copy against production. That gap is your real recovery point—often much larger than assumed.
6. Time the whole thing. From "we've decided to restore" to "staff can work again." That number is your real recovery time, and it's the one to tell management.
7. Write down every step and every surprise. The missing password, the undocumented config file, the licence key you had to hunt for. That document is half the value of the exercise.

Two Numbers Every Owner Should Know

Strip away the technical detail and backup strategy comes down to two business decisions:

• How much data can you afford to lose? If you back up nightly at 11pm and the server dies at 4pm, you've lost a full working day of orders, invoices and payments. Is that survivable? For some businesses yes; for a busy retail or booking operation, absolutely not.
• How long can you afford to be down? Restoring from an offsite archive to newly purchased hardware can take days. Restoring to a standby machine that's already configured can take an hour. The difference is cost, and it's a business decision, not a technical one.

Once those two numbers are stated, the technical work is straightforward. Without them, backup discussions go in circles—because nobody knows what "good enough" means.

A Sensible Baseline for an SME Legacy System

For a typical Malaysian SME running an on-premise .NET application on SQL Server, this is the shape of something defensible without being expensive:

• Nightly full database backups, retained for at least 30 days.
• Transaction log backups every 15–60 minutes if losing a day of work would hurt—this also keeps your log file from growing indefinitely.
• At least one copy offsite or in cloud storage, on a separate account from your day-to-day logins.
• Application files, configuration and any document or image storage included in the schedule, not just the database.
• Automated verification that the backup completed, with failure alerts going to someone who still works at the company.
• A full restore test at least twice a year, documented.
• A written recovery runbook stored somewhere that survives the server being unavailable.

The Ransomware Wrinkle

One thing worth stating plainly: if your backup drive is permanently connected and writable from the server it's backing up, ransomware will encrypt your backups along with everything else. This is now one of the most common ways businesses discover their backup strategy was insufficient.

The defence is straightforward—at least one copy that the production system cannot write to. Offline media rotated regularly, or cloud storage with versioning and separate credentials. It doesn't need to be expensive, but it does need to exist before it's needed.

The Bottom Line

Having backups and being able to recover are different things, and the distance between them is where businesses get hurt. The good news is that finding out costs very little: one restore test, one afternoon, one honest look at how much data you'd lose and how long you'd be down.

If the test goes well, you've bought genuine peace of mind. If it doesn't, you've found out on a quiet afternoon rather than during a crisis—which is the whole point.