Website backups you can actually restore

Almost everyone has backups. Far fewer have restores. The gap between those two things is where businesses lose weeks of work, and it is almost always discovered on the worst possible day.

This is a practical guide to closing that gap: what to capture, how often, where to keep it, and — the part that matters most — how to know it works.

What a complete backup contains

A website is not one thing, and backing up only the obvious part is the most common failure. A restorable backup needs all four of these:

• Application files — your code, themes, plugins, and configuration.
• Uploaded content — images, PDFs, customer attachments. Often the largest and least replaceable part, because it exists nowhere else.
• The database — posts, orders, users, settings. A files-only backup of a WordPress or WooCommerce site restores an empty shell.
• Environment configuration — environment variables, secrets, nginx routes, cron jobs, DNS settings. Rarely backed up, and painful to reconstruct from memory.

Test for the fourth one by asking: if this server disappeared entirely, could I rebuild it from the backup alone? If the answer involves "and then I would remember how the routing was set up", the backup is incomplete.

How often, and how long to keep it

Frequency should follow how much work you are willing to lose:

• A brochure site that changes monthly — daily backups are generous.
• An active blog or content site — daily is right.
• A store taking orders — daily files, but the database needs more. Losing 23 hours of orders is a serious business problem, not an inconvenience.

For retention, a sensible default is daily backups kept for 7–30 days. The reason to keep a month rather than a week is that not all disasters are immediate. A database corruption or a quiet compromise can go unnoticed for a fortnight, by which point a seven-day window contains only broken copies.

The 3-2-1 rule, and the part that matters

The classic guidance is three copies, on two types of media, with one off-site. For a small business the useful distillation is simpler: at least one copy must be somewhere your server cannot reach with its own credentials.

This is the ransomware lesson. Malware that gains root on your server will encrypt or delete every backup that server can write to. A backup on the same disk is not a backup; it is a second copy of the same failure.

The test that makes it real

Here is the exercise worth doing this week. It takes under an hour.

1. Take a fresh backup.
2. Restore it somewhere that is not production — a second server, or a staging environment.
3. Open the restored site. Log in. Load a page that requires the database.
4. Check that uploaded images render, not just that the pages load.
5. Write down how long the whole thing took.

That last number is your real recovery time, and it is usually a surprise. It is also the number to tell people when they ask how long the site will be down.

Things this exercise commonly uncovers: the database dump was empty because credentials changed; the uploads directory was excluded by a stale ignore rule; the backup completed but the archive is corrupt; nobody knows the credentials for the backup storage.

How it works on Simplewala

Backups are included on every server at every size — not a higher-tier feature and not a separate line on the bill.

• Daily snapshots of application files and databases, taken automatically.
• One-click restore from the dashboard to a chosen point in time.
• Database data on persistent block storage, so a server rebuild does not take the data with it.
• Volume-level snapshots for databases, separate from application file backups.

Because you also keep root SSH access, nothing stops you from adding your own off-site copy to storage you control. We would encourage it for anything business-critical — platform backups and an independent copy are complementary, not redundant.

Before any risky change

Automated daily backups protect you from disasters. Manual backups protect you from yourself. Take one immediately before:

• A major plugin, theme, or framework update
• A database migration or schema change
• Editing configuration you do not fully understand
• Handing server access to a new contractor

It takes a minute and turns a potential rebuild into a two-minute rollback.

Backups are not a migration plan

One clarification worth making: restoring a backup onto a new host is a viable way to move, but it is not a zero-downtime move. If you are changing hosts, run both environments in parallel and switch DNS once the new one is verified — the approach described in migrating WordPress with zero downtime.

Backups are your insurance policy. Migration is a planned move. Using the first as the second is how a planned change becomes an unplanned outage.

For where backups sit among the other things protecting your server, see the small business server security checklist.

Keep reading

Server security checklist The eight controls that matter, and which ones are handled for you. Migrate WordPress with zero downtime Move a live site properly instead of restoring a backup and hoping. Moving data without downtime Copy, verify by checksum, test the copy, then promote — with a rollback window. Database hosting Seven engines on persistent block storage with snapshot support.