A Backup You've Never Restored Is Not a Backup

"We have backups." We've heard that sentence many times, and two follow-up questions usually break it: the backup sits on the same server, the last successful backup was three months ago, and nobody has ever tried restoring it. Then comes the day of ransomware, an accidentally dropped table, or a data-center incident — and you discover the "backup" in your hands can't bring anything back. Data is the least renewable asset a business has. Broken code can be rewritten; ten years of customer and transaction records, once gone, are simply gone.

The 3-2-1 rule: the baseline of backup strategy

There's a long-standing mnemonic that still works: the 3-2-1 rule — three copies of your data, two types of media, one copy offsite. In plain terms:

• Three copies: beyond the live original, at least two backups. With only one backup, you're betting everything on two baskets.
• Two media types: don't put everything in the same kind of place — say, one copy on the server's backup disk and one in cloud object storage. Copies on the same medium share the same ways to die.
• One offsite: at least one copy in a physically different location. Hosting-provider data centers have burned; compromised accounts have had everything deleted in bulk — these things really happen. The offsite copy is your last line of defense.

One common blind spot deserves special mention: a "backup folder" on the same server is not a backup. Disk failure, a breach, or a hosting incident takes the original and the backup down together. Another blind spot: sync is not backup — cloud-drive sync will faithfully propagate your accidental deletion to every location.

A backup you've never restored is not a backup

This is the most important sentence in this article. The existence of a backup file doesn't mean it works: it may be incomplete, corrupted, encrypted with a password nobody remembers, or dependent on restore steps nobody knows how to run. A real scenario we've encountered: a backup script ran for a year, silently broke after a system upgrade, and produced empty files every day thereafter — monitoring only checked "did the script run," never "does the file have content."

That's why restore drills are a mandatory item in our delivery standard: periodically (at least quarterly), actually restore the backup to a test machine, confirm the data is intact and the system runs, and record how long the whole restore took. That duration has a proper name — RTO (recovery time objective: "how long until we're back in business after everything dies"). The question an owner should really ask isn't "do we have backups?" It's "if the database were destroyed right now, how many hours until we're operating again — and how many hours of data would we lose?" If you can't answer those two numbers, your backup strategy isn't finished.

A backup isn't a file — it's a rehearsed capability to recover. Everyone has files. Capability is what's worth money.

Frequency and retention, practically

Frequency depends on how much data loss you can tolerate. E-commerce and retail systems transact daily, so the common practice is a full daily database backup plus more frequent transaction-log backups, shrinking potential loss to under an hour. A pure brochure site may be fine with weekly. For retention, keep multiple generations — dailies for seven days, weeklies for four weeks, monthlies for several months — because some disasters are slow-moving: corrupted data discovered two weeks later means that if you only kept the last three days, the clean version was overwritten long ago.

The inventory-management SaaS we operate supports franchise stores' daily receiving and shipping, and backups plus restore drills are scheduled routine operations — not something remembered after an incident. This isn't advanced technology. It's just discipline.

A checklist for owners

You don't need to be technical — take these five questions to your system vendor or IT: How often do backups run? Where are they stored, and is one offsite? When was the last successful restore drill? After total loss, how long to recover? Who gets alerted when a backup fails? If more than two of the five draw blanks, it's time to worry. Incidentally, backups are also the foundation of system replacement and data migration — the precondition for a stress-free move is being able to roll back from any botched step.

If you're not sure your current system's backups are reliable, come to us for a health check and get all five answers filled in at once. This kind of check is best done before an incident — afterward it's not a health check, it's emergency surgery.