Practical guide

Backups: what to save and how to test them

Many sites have “backup enabled” in the panel but nobody has tried restoring. This guide clarifies what to save, how often, and how to check that a backup will actually help when something breaks.

Backups: what to save and how to test them

What to back up (and what is often missing)

A useful backup includes site files and the database. In WordPress that means wp-content, the core if customized, and the full database — not random partial tables.

Also document outside the backup: DNS, domain email MX records, certificates if self-managed, integration keys (gateways, CRM, APIs), and the list of active plugins with versions.

  • Files: themes, plugins, uploads, and any custom folder outside wp-content.
  • Database: full dump, not a careless partial export from phpMyAdmin.
  • Server configuration that affects the site: PHP, cron, cache rules.
  • Email: if mailboxes live on hosting, plan their backup or migration separately.

How often to back up

There is no universal rule: it depends on how often the site changes and how critical it is to lose the last few hours of data.

A blog that publishes once a month does not need hourly backups. A store with daily orders needs frequent copies and several days of retention.

  • Corporate site with occasional changes: daily or weekly backup may be enough.
  • Store or site with critical forms: daily at minimum; ideally several copies per week.
  • Before updating plugins, themes, or core: immediate manual backup.
  • Before migrating or touching DNS: verified copy at destination and origin.

Where to store backups

A backup that only lives on the same server as the site does not protect you if hosting fails, your account is suspended, or ransomware encrypts the whole disk.

The practical rule is 3-2-1: three copies, on two different media, one off the primary server. You do not need an expensive system; you do need not depending on a single panel.

  • Copy in the hosting panel (fast to restore, but not enough alone).
  • Copy in external storage: S3, business Google Drive, Backblaze, etc.
  • WordPress backup plugin only if well configured and sending off-server.
  • Avoid public copies reachable by URL without authentication.

How to test that a backup works

Restoring is the only real test. Many discover the backup fails when they already lost the live site.

Ideally use staging or a test subdomain where you restore a recent copy and verify login, forms, menus, and — if applicable — checkout.

  • Restore a copy from last week on staging at least once per quarter.
  • Check that images load (uploads included in the backup).
  • Verify internal links and admin login work.
  • Note how long restore took: in an incident that time matters.

When to get help

It makes sense to contact us if you never restored a backup, if the site outgrew the panel backup, if you are migrating and are unsure what to include from email, or if you need automated backups with clear retention without relying on a single plugin.

In an initial review we look at what you have today, the real risk, and the minimum change that gives peace of mind — without selling storage you will not use.

Want to get back to what you're building?

Tell us your situation: we'll see what to hire, configure it with you, and give you clarity — so you stay focused on what you're building, not another pending technical issue. No commitment on the first reply.

Contact us