WordPress Backup Strategy for Small Businesses

Most owners find out their backup plan does not work on the day they need it. A plugin update takes the site down, and hosting support replies that the newest copy is older than you assumed. Everything added since then, including enquiries sitting in the database, has to be recreated from memory.

A backup strategy is not one plugin you install and forget. It is a short set of decisions: what gets copied, how often, where the copies sit, who checks that they still run, and whether anybody has ever restored one. Here is how to settle those decisions for a normal business site.

What your hosting company is actually keeping

Almost every hosting plan mentions backups somewhere in the feature list. That line is usually true and usually not enough on its own. Host backups exist so the hosting company can rebuild a server, not so you can recover the page you edited last Tuesday.

Open your hosting panel and check four things before you trust it.

• How far back the copies go, and whether they are daily or weekly
• Whether you can restore yourself, or have to raise a ticket and wait
• Whether the copy is stored on the same server as your site
• Whether a restore costs extra, and whether it can bring back single files

That third point catches people out. On many shared plans the backup sits on the same machine as the website, so a failed disk or an account suspended over a billing mix up puts the copy out of reach at exactly the wrong moment. Host backups are one layer, not the whole plan.

A WordPress site is two things, and you need both

WordPress splits into files and a database. The files are WordPress itself, your theme, your plugins, and the uploads folder holding every image and PDF ever added. The database holds pages, posts, products, orders, users, settings and most plugin configuration. A copy of one half without the other is close to useless.

This is where partial backups hide. An export of your content as an XML file gives you posts and pages, but not images, not theme settings, and not WooCommerce orders in a form you can use. Syncing one folder to a cloud drive gives you images and no content. When you open a backup, you want to see both parts: a database dump and the site files.

The uploads folder grows fastest and is often most of the backup size, so owners with years of photos sometimes exclude it to save space and forget they did. Plugins are the opposite, since the same versions can be downloaded again. If you must choose what to protect hardest, protect the database and the uploads.

How often to back up depends on what you would have to retype

There is no single correct frequency. The useful question is simple. If the site jumped back to yesterday morning, what work disappears, and who has to redo it?

Answer that honestly and the schedule picks itself.

• A brochure site edited a few times a year: weekly, plus a manual copy before any update
• A site with a blog and contact forms: daily files and database, since enquiries cannot be recreated
• A WooCommerce shop: daily files, and the database more than once a day
• Before a migration, a theme change or a PHP version change: a copy you download yourself

Retention matters as much as frequency. Daily copies with two days of history do nothing about a problem that started quietly, such as a modified file or a form that stopped sending mail. A pattern that holds up: daily copies for a fortnight, weekly copies for a couple of months, and one copy per month for the year.

Where the copies should live

One copy in one place is a single point of failure. The old rule from IT teams still works for a small business: more than one copy, in more than one place, with at least one somewhere the website itself cannot reach.

In practice that means the automatic backup your plugin or host creates, pushed out to remote storage such as Google Drive, Dropbox or an S3 style bucket, plus a copy you download to a laptop or office drive now and then. The downloaded one survives losing access to the hosting account, which happens through lost logins and billing disputes more often than through hardware trouble.

Keep the storage account separate from the site. If the same credentials that run the website can also delete the backups, one compromised admin account takes out both. Tightening admin access, which we cover in our guide to WordPress security for a business site, also reduces how often you need the backups at all.

A backup nobody has restored is not a backup

This is the step almost everybody skips. A backup file is a promise that it can be turned back into a working website. Until somebody has actually done that, it is a file with a hopeful name.

Restores fail for dull reasons. The database dump is present but truncated. The archive was written while the site was live, so some files come from before an update and some from after. The plugin that made it needs a licence that lapsed. The archive is encrypted with a passphrase nobody recorded. The server has moved to a newer PHP version and the old code refuses to run.

Test on a copy, never on the live site. Most hosts offer a staging site in a click or two, and tools like LocalWP let you rebuild the site on your own computer. Run the drill once when you set the system up, then once or twice a year. Open the home page, an inner page, the contact form and the admin login. Note how long it took, because that is your real recovery time. If something has already gone wrong, what to do when a site is hacked covers the order of steps.

Give the plan an owner and a written procedure

Backups fail silently. A plugin stops running after a server update, the cloud storage quota fills, an access key expires, and nothing tells you until the day you go looking for the file. So the plan needs a name attached to it.

Write down four things and keep them where more than one person can see them: what is backed up, where the copies go, who checks the monthly report, and the steps to restore. Store hosting and cloud logins in a password manager the business owns, not an employee inbox. If an agency runs the site, ask for a copy you keep yourself. The wider version of this habit sits in our website security checklist for owners.

Migrations test all of this whether you planned for it or not, which is why our own WordPress migration and backup plugin, SiteShift Migrator, produces a full copy you can download before anything moves. The tool matters less than the routine. A modest schedule someone checks every month beats a clever setup nobody looks at.

FAQs