Backups that won't save you: why having a backup isn't enough

"We have backups." It's the phrase every website owner says with confidence — and the one that becomes hollow the day they actually need them.

According to the National Cyber Security Alliance, 60% of small businesses that lose critical data close within 6 months. Most thought their backups were fine, until they weren't.

This post explains why backups fail when you need them most, what a professional system looks like, and how to know if yours actually work.

The "we have backups" myth

There are three common ways backups fail:

1. They've never been tested

A backup that's never been restored is just a file with a nice name. It could be corrupt, incomplete, or in a format your system can no longer read.

Tape backups in the 90s were notorious for this — companies ran daily backups for 10 years, then needed them and discovered the last successful restore had been 4 years earlier.

Same problem with modern backups if you never test them.

2. They're on the same server

"We back up daily to the same machine." If the data center goes down, the disk fails, or an attacker encrypts everything, that backup is lost with the original.

3. They're too old

Weekly backups in an active business = up to 7 days of work lost when something happens. If you're processing orders, that's a serious problem.

The 3-2-1 rule (the professional standard)

The classic backup rule that still applies:

• 3 total copies of the data
• 2 different media types (e.g. local disk + cloud)
• 1 off-site copy (away from your physical location)

For a website:

• Copy 1: Database + files on the production server
• Copy 2: Automatic daily backup in the same data center but separate storage
• Copy 3: Weekly backup to a second cloud provider (S3, Backblaze B2, etc.)

What a serious plan should back up

"The site" isn't specific enough. You need:

Complete database

• Full SQL dump, not selected tables only
• Include users, settings, content, orders, everything
• Compressed to save space

Site files

• Source code
• Uploaded images
• Downloadable documents
• Server configurations (Nginx, Apache, etc.)

Server configuration

• .env files (critical!) — without these, the site won't start
• SSL certificates
• Cron job configurations
• Firewall rules

What you DON'T need to back up

• Cache (can be regenerated)
• Old logs (eat space without recovery value)
• Temporary upload files

Frequency: how many backups you need

Depends on the business:

Rule of thumb: look at how much data loss you can tolerate. If losing 24 hours of orders costs you more than paying for hourly backups, do hourly backups.

Retention: how long to keep them

Having "the last backup" isn't enough. You need a chain:

• Daily: keep the last 7
• Weekly: keep the last 4
• Monthly: keep the last 6

Why multiple points in time: if a hacker silently modifies your database and you notice 3 weeks later, yesterday's backup already has the damage. You need a backup from before the hack to recover.

Verification: how to know they work

Untested backups aren't backups. A serious plan includes:

1. Automated testing

Every month, a script:

• Downloads the most recent backup
• Restores it to a separate staging server
• Verifies the app boots
• Verifies the database has expected tables
• Emails the result

If something fails, someone fixes it before it's a real emergency.

2. Annual drills

Once a year, simulate a full recovery:

• Pretend the production server burned down
• Restore everything from backups to a new server
• Measure how long it took
• Identify which steps were ambiguous or slow

Document the process. If someone new joins the team and has to do a recovery, they should be able to follow the steps.

3. Size monitoring

If the typical backup is 2GB and suddenly it's 50KB, something's wrong. A serious plan alerts when size deviates significantly.

Questions to ask about your current backups

Ask whoever manages your site:

1. How many copies of my data exist right now and where are they?
2. When was the last backup tested with a full restore?
3. How long would recovery take if the production server died?
4. What happens to my backups if the hosting provider shuts down?
5. Can I see the log of successful backups over the last month?

If clear answers don't come back, your backups probably won't save you when you need them.

How we handle it

Every SoftInWeb maintenance plan includes:

• Daily automated backups (database + files)
• Retention: 7 daily + 4 weekly + 6 monthly
• Off-site storage (different provider from hosting)
• Automated monthly restore test
• Monthly report on backup status

Reach out if you're not sure about the state of your current backups — we'll give you a free audit.