Website Backup Strategy for WordPress and Custom PHP Sites

Losing a website is not a hypothetical problem for small businesses in the UK. It happens when a hosting provider has an outage, a failed update corrupts files, a developer makes a migration mistake, or a security incident wipes data. Without a working backup, recovery can be expensive, slow, or in some cases impossible. A solid website backup strategy is one of the most practical investments a small business can make in its digital presence.

This article covers what a real backup strategy looks like for both WordPress sites and custom PHP applications. It explains the components that matter, the mistakes that cause avoidable problems, and how to decide whether to handle it yourself or bring in someone who manages this professionally.

What a website backup strategy actually needs to cover

A backup is not just a copy of your files. For a business website, a complete backup strategy includes several distinct components:

• Full file system backup: All website files including themes, plugins, uploaded media, and custom code.
• Database backup: All content, user data, settings, order records, and configuration stored in MySQL or MariaDB.
• Retention schedule: How many backup copies to keep and for how long.
• Offsite storage: A copy stored somewhere separate from your web server.
• Backup verification: Regular checks that backups can actually be restored.
• Recovery procedure: Documented steps for getting the site back online after an incident.

Skipping any of these components creates a gap that can turn a minor incident into a serious business problem.

Why WordPress sites need a different approach than most people assume

WordPress stores its content across two different systems. The file system holds themes, plugins, and uploaded media. The database holds posts, pages, comments, user accounts, plugin settings, and much of the site configuration. Many WordPress owners only back up files and believe they have protection, but a file-only backup will not restore a corrupted database or recover accidentally deleted content.

WordPress plugins like UpdraftPlus, BackupBuddy, and WP-DB-Backup can automate both components. However, plugin-based backups have limits when the WordPress installation itself becomes unstable. If the site cannot load, a plugin may not run to restore itself. Server-level backups or snapshot tools that run outside WordPress often provide more reliable coverage.

For sites running custom PHP code on top of WordPress, the complexity increases. Custom post types, custom database tables, and bespoke functionality may not be included in standard plugin backup configurations. A review of what the backup actually captures is essential before relying on it.

The 3-2-1 rule and what it means for a small business website

The standard guidance for backup strategy follows the 3-2-1 rule: keep three copies of your data, on two different types of storage media, with one copy stored offsite. For a small UK business website, this translates to:

• Primary copy: Your live website files and database on the web server.
• Secondary copy: A backup stored on your hosting account, typically in a separate backup directory or snapshot system provided by the host.
• Offsite copy: A backup stored somewhere completely outside your hosting environment, such as a cloud storage bucket, a local computer, or a remote backup service.

Relying solely on the hosting provider's backups is a common mistake. Most hosting providers keep backups for a limited window, often seven to thirty days, and these backups may not be accessible during a severe outage affecting their systems. Offsite storage ensures that even a catastrophic hosting failure does not destroy your only recovery option.

Setting up a practical backup workflow for WordPress

A reliable WordPress backup workflow combines automated scheduled backups with manual verification steps. Here is a practical approach that works for most small business WordPress sites.

Step 1: Choose your backup destination

Configure your backup plugin or server-level tool to send copies to at least two locations. Common options include:

• Cloud storage: Amazon S3, Google Cloud Storage, or Backblaze B2 provide inexpensive offsite storage with good reliability.
• Local storage: An external drive or local server that your team can access without internet connectivity.
• Managed backup service: Services like BlogVault run backups on their own infrastructure, which can be useful when the site itself is compromised.

Step 2: Set a schedule that matches your update frequency

If you publish new content daily, a daily backup schedule makes sense. If your site changes infrequently, weekly backups may be sufficient. The key is matching the schedule to how much data you could afford to lose.

For e-commerce sites or booking systems where new orders or bookings arrive throughout the day, real-time or multiple daily backups reduce the risk of losing transaction records. For a content-focused site like a blog, daily is usually adequate.

Step 3: Test your backups at least quarterly

Having a backup that cannot be restored is worse than having no backup at all. Set a calendar reminder to restore a backup to a staging environment at least once every three months. This confirms that the backup file is valid, complete, and that the restoration process works as expected.

Custom PHP sites require a different backup approach

Custom PHP applications do not have the ecosystem of backup plugins that WordPress offers. The backup strategy for a custom PHP site relies more heavily on server-level tools and manual processes.

Database backup using mysqldump

For MySQL or MariaDB databases, the standard tool is mysqldump. A typical command to create a full database backup looks like this:

mysqldump -u username -p database_name > backup_2026_01_15.sql

This command exports the entire database to a SQL file. For a live site, scheduling this via cron ensures it runs automatically:

0 2 * * * /usr/bin/mysqldump -u wpuser -p'password' dbname > /backups/db_$(date +\%Y\%m\%d).sql

Running this daily at 2 AM is a common starting point for small business sites with daily content changes. Adjust the time and frequency based on how often your data changes.

File system backup using tar

To back up website files, tar creates a compressed archive that is easy to store and transfer:

tar -czvf site_backup_2026_01_15.tar.gz /var/www/html/

For automated daily backups, a cron job or a simple bash script can handle rotation and retention. Keeping the last 7 daily backups and 4 weekly backups is a common retention pattern that balances storage cost with recovery needs.

Transferring backups offsite

Local backups alone do not satisfy the 3-2-1 rule. Use a secure transfer method to move copies off the server:

• rsync over SSH: Efficient for incremental file transfers to a remote server.
• S3 CLI: The AWS command line interface can push backup files directly to S3 buckets.
• scp: A straightforward secure copy command for smaller backup files.

Keep credentials secure. Store backup transfer credentials separately from the production server, ideally using environment variables or a secrets manager rather than hardcoding passwords in scripts.

Common backup mistakes that cause real problems

Several backup strategies look adequate on paper but fail when you need them most.

Only backing up files

Many small business owners use hosting control panel file backups without realising their database is not included. Restoring file backups without the database leaves a site in a broken state. Always confirm that both components are covered.

Assuming hosting backups are always available

Hosting providers typically limit how long they retain automated backups. Some retain them for 7 days. Others may suspend or delete backups if an account is suspended or if storage limits are reached. Treat hosting backups as a convenience layer, not a primary recovery solution.

Never testing restoration

A backup that cannot be restored is worthless. Without regular testing, you only discover a failed backup when you are already dealing with an emergency. Quarterly restoration tests on a staging environment catch problems before they become crises.

Backups stored on the same server

Storing backups in a subdirectory of the same hosting account offers almost no protection against server failures, filesystem corruption, or account-level issues. Offsite storage is not optional for business sites.

No documented recovery procedure

When an incident happens, the last thing you want is to be reading documentation while the site is down. A documented recovery procedure that your team can follow reduces downtime and prevents mistakes made under pressure.

How long should you keep backups

Retention depends on the nature of your site and regulatory requirements. For most small UK businesses:

• Daily backups: Keep for 7 to 14 days to cover recent incidents.
• Weekly backups: Keep for 4 to 8 weeks to cover situations discovered too late for daily retention.
• Monthly backups: Keep for 3 to 12 months if your site does not change frequently and you need a long-term recovery option.

If your site handles personal data, consider how long you need to retain records for compliance purposes and align your backup schedule accordingly. GDPR does not require endless retention, but it does require that you can respond to data subject requests, which may involve accessing historical data.

When a backup strategy needs professional help

Setting up automated backups and offsite storage is achievable for most technical users. However, several situations typically benefit from having an experienced person review or implement the setup:

• Custom database schemas: If your custom PHP application uses multiple databases, custom table structures, or scheduled data processing, a standard backup script may miss critical components.
• Large file volumes: Media-heavy sites with thousands of images or large video files need efficient backup strategies that avoid timeouts and excessive storage costs.
• Migration planning: Moving a site to new hosting requires a verified backup and a tested restoration process before any work begins.
• Security incidents: If a site has been compromised, restoring from a backup made before the compromise is necessary, but the cause of the breach should also be identified and fixed to prevent repeat incidents.
• Ongoing maintenance: Many small businesses do not have anyone monitoring whether backups are actually running. A managed support arrangement can include regular verification and testing.

What a backup strategy review typically involves

When I review a website's backup setup, the process usually covers several areas:

• Checking what is currently backed up and whether it is complete.
• Verifying backup schedules match the site's change frequency.
• Confirming that offsite storage is configured and accessible.
• Testing a restoration in a staging environment.
• Documenting the recovery procedure in plain language.
• Identifying any gaps that need addressing before they cause problems.

This type of review usually takes a few hours for a standard WordPress or custom PHP site and provides clarity on what would happen in a recovery scenario.

Comparing backup approaches by platform type

The right backup method depends on how your site is built and hosted. Here is a practical comparison for common scenarios.

Moving between platforms and keeping backups safe

If you are considering moving from WordPress to a custom PHP solution or switching hosting providers, backups become especially important. A failed migration can corrupt data if you do not have a verified copy to fall back on. Before any migration work begins, confirm that a complete backup exists, that it can be restored locally, and that you have a clear rollback path if the new setup does not work as expected.

The decision between WordPress, custom PHP, and website builders affects more than just development. Backup strategy, maintenance overhead, and recovery complexity all shift depending on which platform you choose. Understanding the implications early prevents surprises later.