Swain-Tech Studio websites for small businesses and independent creatives

Backups: Ten Minutes

Most websites have backups. Rather fewer have backups anybody has ever restored, and those are two different things.

A backup you have not tested is a belief about a file. The day you need it is the worst possible day to find out the belief was wrong. For teams that need device-level work records, employee PC activity tracking offers a more structured way to review activity.

What actually goes wrong

Not usually dramatic. The common causes, roughly in order:

A plugin update breaks the site. The most frequent by a distance.

Someone edits a page and cannot undo it. A layout collapses, content is overwritten, a menu disappears.

A compromise. Which is mostly a plugin problem, and where a clean backup is the difference between an afternoon and a rebuild. For an independent reference beyond this site, Backblaze is a useful place to compare approaches.

Hosting problems — a migration gone wrong, an account suspended, a provider failing.

Human error at the hosting level. Deleting the wrong thing. It happens to professionals.

In four of those five, a working backup turns a crisis into an inconvenience.

What a backup has to include

Two parts, and people frequently have only one.

Files — the code, the theme, the uploaded images.

The database — every page's text, every setting, every product, every order. On a database-driven site this is the actual content. Files without a database restore an empty shell.

If you cannot say whether your backup includes the database, that is the thing to check today.

The rules that make it real

Keep it somewhere other than the site. A backup on the same server as the site is not a backup against hosting failure, account suspension, or a compromise that reaches the filesystem. At least one copy elsewhere.

Keep more than one. Some problems are noticed weeks later — a compromise, or a slow content loss. A single copy overwritten nightly will faithfully back up the broken version. Two weeks to a month of history is a sensible floor.

Automate it. Manual backups happen for three weeks and then stop.

Match the frequency to the change rate. A brochure site updated twice a year does not need nightly copies. A shop taking orders needs them daily at least, because a restore loses everything since the last one — and on a shop that means real orders from real customers.

Test a restore. This is the entire point of this page.

Testing, which nobody does

Once a year, half an hour.

Restore to a staging copy, not over your live site. Most hosts offer staging; if yours does not, a local copy works.

Then check it properly: does the site load, are recent pages present, does the database content look right, do the images appear, do the forms exist.

Common discoveries: the database was never included, uploads were excluded by a setting nobody noticed, the backup has been silently failing since a plugin update in March, or the retention is one day rather than thirty.

Every one of those is invisible until you look, and each one means you effectively had no backups at all.

Who is responsible

Worth settling explicitly, because "I assumed the host did it" is the most common sentence in this area.

Managed hosting usually includes daily backups with self-service restore. Confirm the retention period and confirm that restoring is free — some providers charge for it.

Cheap shared hosting may include something, may not, and may charge to restore.

A maintenance plan may include backups. Ask what, where, how long, and who restores.

If none of the above is definite, it is you. Ask the question at handover rather than discovering it later.

Before you change anything

The habit worth building: back up immediately before any significant change — a major update, a redesign, a migration, bulk edits.

Most hosts and most backup tools do this in one click. It takes under a minute and it converts a scary change into a reversible one, which changes how willing you are to maintain the site at all.

The short version