Website Backups and Disaster Recovery: A No-Excuses Setup

Three disasters, one common thread

Website disasters come in three flavours, and every small business is exposed to all of them. The hack: an out-of-date plugin gets exploited, the site starts serving spam or malware, and Google flags it in search results. The host failure: an account is suspended over a billing mix-up, a server dies, or a budget host simply disappears, taking your files with it. The bad update: a plugin, theme or platform update white-screens the site on a Friday afternoon, or an edit to a template takes the checkout down.

The common thread is that the damage is not decided when disaster strikes. It was decided weeks earlier, by whether the backups you would now give anything for actually exist, live somewhere the disaster cannot reach, and restore cleanly. This article sets that up, permanently, in an afternoon.

The 3-2-1 rule in plain English

The 3-2-1 rule has survived decades because it covers every failure mode: keep three copies of your data (the live site plus two backups), on two different types of storage, with at least one copy offsite, meaning away from your web host.

The offsite part is the one people skip and the one that matters most. A backup stored in the same hosting account as the site protects you from a bad update, but not from a suspended account, a compromised server or a host that vanishes. If your only backups live with your host, you do not have backups; you have a single point of failure with extra steps.

Retention matters too. Keep at least 30 days of versions, because hacks are often discovered weeks after they happen, and last night's backup of a compromised site is just a compromised site with a timestamp.

Setup by platform

WordPress

Install UpdraftPlus (the free version is enough) and schedule database backups daily and file backups weekly, sending both to Google Drive, Dropbox or Backblaze B2 rather than the server itself. Keep your host's own cPanel or JetBackup snapshots running as the second copy. Ten minutes of configuration, then it runs forever.

Shopify and other hosted platforms

The platform's infrastructure is backed up; your mistakes are not. If you delete products or break a theme, that is your problem. Export products, customers and orders to CSV on a monthly schedule, duplicate your theme before every edit, and consider a dedicated backup app such as Rewind if the store is your main income.

Static and custom-built sites

Code belongs in Git, with a private GitHub or GitLab repository serving as your offsite copy. If there is a database, dump it nightly by cron job to object storage such as Backblaze B2 or S3, and document any server configuration your developer would need to rebuild the box.

What people forget to back up

The files-and-database pair is not the whole business. When you write your setup down, include:

• Uploaded media and customer documents, which often live outside the main file backup
• Email, if your mailboxes sit on the same hosting account as the site
• DNS records: export or screenshot them, because rebuilding DNS from memory mid-crisis is grim
• Licence keys for premium plugins, themes and fonts
• Environment configuration and API keys, stored in a password manager rather than a text file
• The credentials for the backup services themselves, kept somewhere that does not depend on the site being up

The restore test: quarterly, non-negotiable

An untested backup is a hope, not a plan. Backup jobs fail silently: storage fills up, an API token expires, a plugin update breaks the schedule, and the reassuring green ticks keep appearing anyway. The only proof is a restore.

• 1. Create a staging area: a subdomain on your hosting, or a local environment such as LocalWP for WordPress
• 2. Restore your most recent backup into it, following your own written steps
• 3. Click through the key pages, log in to the admin, and submit a test form
• 4. Time the whole exercise; that number is your real recovery time
• 5. Put a recurring calendar entry in for the same drill every quarter

While you are at it, point a free Healthchecks.io monitor at the backup job so you are alerted the week it stops running, not the day you need it.

A one-page disaster recovery plan

Finish by writing a single page and storing it outside the website: where the backups live and where the credentials are, the restore steps you have now rehearsed, your host's support contact and your developer's number, and the registrar and DNS logins. Add two decision rules: if hacked, take the site offline, restore a clean version from before the compromise, change every password and update everything before relaunch; if the host is down beyond a day, restore the offsite copy to a new host and repoint DNS.

Include a communication line too: a simple holding page and a short message for customers beats silence. With 3-2-1 backups, a quarterly drill and this one page, a disaster becomes an inconvenient afternoon rather than an existential threat. If you would like this whole setup built, tested and monitored for you, our maintenance team can take it off your plate.