My store has backups, but would they actually restore?

There are backups somewhere, but nobody has ever restored one

Ask most store owners about backups and the answer is "the host does them" or "there's a plugin". Ask when a backup was last restored, and the answer is usually never. Ask where the backups are stored, who has the login, and how long a restore would take, and the room goes quiet.

That's normal, and it's risky. Backups get set up once, at launch, and then run in the background for years. Nobody looks at them until the day the site is hacked, a plugin update corrupts the database, or someone deletes the wrong thing. That's the worst possible day to find out the backup is incomplete.

Why it happens

Backups rarely fail loudly. They fail in ways nobody notices until a restore:

The backup lives on the same server

Many backup plugins store their archives in a folder on the same server as the site. If the server fails, the account is suspended, or an attacker deletes files, the backups go too. A backup that shares a failure with the thing it protects isn't a backup.

The database is missing or incomplete

Some setups back up files but not the database, or the reverse. Others time out on a large database and save a partial dump without an error anyone reads. For a store, the database is the business: orders, customers, products and settings. Files can often be rebuilt. Orders can't.

Files are partial

Archives exclude the uploads folder to save space, or skip files over a size limit, or stop when the disk fills up. The restore brings back a site with missing product images and no one knows why.

Retention is too short

Backups that keep only the last few days don't help if a hack or a corrupted table went unnoticed for two weeks. By the time you look, every backup already contains the problem.

Credentials are lost

The backups exist in a cloud storage account set up by a previous developer, with a login nobody has, or encrypted with a key nobody wrote down.

Nobody tests them

Each of the problems above is easy to catch with one test restore. Without a test, they stay hidden for years.

What fixing it involves

1. A backup setup you control

I set up automated backups that meet a few rules:

• Off-site. Stored with a separate provider, such as Backblaze B2, in an account you own. The host's own backups stay in place as a second layer.
• Files and database. The full file tree, including uploads, and a consistent database dump, checked for completeness after each run.
• Scheduled by risk. The database more often than the files, because every order changes it.
• Sensible retention. Daily, weekly and monthly copies kept long enough to go back past a problem nobody spotted at once.
• Encrypted. Encrypted before upload, with the key stored somewhere you control and written into the recovery plan.
• Protected from deletion. Backup credentials that can write new backups but not delete old ones, or object lock where the provider supports it, so an attacker on the server can't erase the history.
• Monitored. An alert if a backup job fails or doesn't run, so a silent failure doesn't last months.

2. The monthly restore test

Once a month I restore the latest backup to a staging server, never over the live store. The steps:

1. Fetch the backup from off-site storage using the credentials in the recovery plan, not from the live server. This proves the credentials and the storage both work.
2. Restore files and database to a fresh staging environment.
3. Point it at a staging domain and block it from search engines and from sending email, so customers never get a message from the test copy.
4. Check the site works. Home, category and product pages, images, the admin, and the most recent orders and customers.
5. Check the data is current. Compare the newest order in the restored database with the live store, so you know exactly how many hours of orders a restore would lose.
6. Time it. Record how long the restore took from start to working site.
7. Write it down. Date, backup used, time taken, anything that failed, and what was fixed.

Then the staging copy is deleted.

3. WooCommerce specifics

Restoring a store is harder than restoring a blog, because orders keep arriving. If you restore last night's backup at noon, the morning's orders, customers and stock changes are gone. Before any real restore, I export everything created since the backup from the damaged site, if it's still readable, and from the payment provider's dashboard, then re-import or re-create those orders after the restore. Payment gateway webhooks and scheduled subscription renewals need checking too, so nothing is charged twice or missed.

4. A written recovery plan

The last piece is a short document you can read under stress: where the backups are, who has the logins, how to restore, how long it takes, who to call, and what to check afterwards. It lives outside the server it describes.

If you're unsure what your current backups would bring back, I can check them as part of security, infrastructure and site care. If the site is already down or hacked, go straight to the emergency page.