If a plugin update breaks your website tomorrow, how confident are you that you can restore it quickly? Many small business owners discover gaps in their backup strategy only when they genuinely need a restore. By then, it is usually too late to fix what was missing.
A solid backup strategy for WordPress and custom PHP sites is not about having one copy stored somewhere. It is about knowing what to back up, how often, where it lives, and whether it can actually be restored when something goes wrong. This guide walks through the practical decisions that matter for UK small business websites.
Why backup strategy is different for WordPress and custom PHP sites
WordPress and custom PHP applications store data in similar ways, but their backup requirements differ in practice. WordPress sites typically rely on a mix of core files, a theme, multiple plugins, uploaded media, and a database. Custom PHP applications may have their own database structure, configuration files, session handling, and file upload directories that do not follow the WordPress convention.
Understanding what belongs in a backup for your specific setup matters. A backup that misses the uploads folder, the database, or the configuration file is not a complete backup. It is a partial one that will cause problems when you try to use it.
The three components every website backup must include
Most website failures involve one of three things going wrong: the database, the files, or the ability to connect to the server. A complete backup strategy addresses each component separately.
Database backups
The database is where your content, user data, settings, and often plugin configurations live. For WordPress, this is the MySQL or MariaDB database that stores posts, pages, comments, user accounts, and site options. For custom PHP applications, the database structure varies, but the principle is the same: if the database is lost, the content is lost.
A database backup should include a full export using mysqldump or an equivalent tool. Running this from the command line gives you more control than relying solely on a plugin interface.
mysqldump -u username -p database_name > backup_date.sqlFor automated backups, a cron job can run this daily or more frequently depending on how often content changes. The exported SQL file is a plain text file containing all the commands needed to rebuild the database on a new server or after a restore.
WordPress stores most dynamic data in its database, but the database does not hold your uploaded files, theme files, or plugin code. Those live in the file system and need their own backup process.
File system backups
For a WordPress site, the file system backup should cover the entire installation directory. The most important parts are usually the wp-content folder, which contains themes, plugins, and uploaded media, and the root configuration file wp-config.php, which holds database credentials and site-specific settings.
Uploaded media is often the largest part of a WordPress file backup. Many sites accumulate years of images, documents, and other files in the wp-content/uploads directory. Missing this folder after a restore means losing every image ever uploaded to the site.
For custom PHP applications, map out which directories contain code, configuration, uploaded files, logs, and temporary data. A custom PHP site may store configuration outside the web root, store sessions in files, or keep assets in directories that are not immediately obvious. Understanding the application structure before writing a backup script prevents surprises during a restore.
tar -czf website_files_backup_$(date +%Y%m%d).tar.gz /var/www/html/This command creates a compressed archive of the entire web directory. Storing this archive off-site ensures it survives server hardware failures.
Configuration and environment files
Configuration files are easy to overlook because they rarely change after initial setup. However, losing a wp-config.php file, a .env file for a custom PHP application, or server configuration files means rebuilding settings from memory. This is error-prone and time-consuming.
Include these files in every backup and verify they are readable and complete when testing a restore.
Why off-site storage is not optional
A backup stored on the same server as the live website is not a backup in the practical sense. If the server fails, if the disk dies, or if an attacker gains access and corrupts data, local backups can be affected too. Real backup strategy separates the data.
The 3-2-1 rule is a widely recognised standard for data protection: keep at least three copies of your data, on two different types of storage media, with one copy stored off-site. For most small businesses, this means having a local backup for quick access and a cloud backup for disaster recovery.
Cloud storage options for small businesses include services that integrate with server scripts, backup plugins for WordPress, or manual file transfers to a storage bucket. The key is ensuring that the cloud copy is independent of the server and that it is updated automatically or on a set schedule.
If you are comparing cloud backup solutions, check whether the service supports versioning, encryption at rest, and a clear restore process. A cloud backup that is difficult to restore is not much help in an emergency.
Testing restores: the step most people skip
Having a backup is only half the equation. Whether the backup can be restored successfully is the other half, and it is the half that often goes unchecked until it matters most. I have seen servers with months of daily backups that turned out to be corrupt, incomplete, or dependent on a server state that no longer existed.
Testing a restore involves more than checking that a file exists. It means setting up a clean environment, extracting the backup, importing the database, verifying file permissions, and checking that the site loads correctly. This does not need to be a full production restore every time, but it should be a genuine restore test, not just a file integrity check.
A practical approach is to maintain a staging environment that mirrors the production setup. Backups can be restored to staging on a regular schedule to confirm they work. This catches problems before they become urgent. If you do not have a staging environment yet, consider setting one up specifically for restore testing.
The process of testing also reveals gaps. You may discover that a plugin stores critical settings outside the database, that uploaded files are stored on a separate volume not included in the backup, or that the backup script has been failing silently for weeks. These discoveries are valuable because they can be fixed while there is still time.
Staging environments and pre-update checks
Before applying WordPress core updates, plugin updates, or theme changes to a live site, running those changes in a staging environment first is one of the most practical risk reduction steps available. A staging environment is a copy of the site that runs separately from production, allowing you to see what happens without affecting real visitors.
Many hosting providers offer staging functionality built into their control panels. For custom PHP applications, setting up a staging environment requires manually copying files and the database, updating the configuration to point to the staging database, and ensuring the staging site is not publicly accessible.
Before making any update, check the following in staging:
- Apply the update in staging: Install the plugin or theme update and run the database migration if one is included.
- Check for errors: Load the site, test key pages, and check the server error logs for unexpected warnings or failures.
- Verify plugin compatibility: Some plugin updates change database tables or remove features that other plugins depend on.
- Test critical functionality: If the site has a contact form, a booking system, or an e-commerce checkout, test those in staging before updating production.
- Take a fresh backup: Before updating the production site, confirm a complete backup exists and that it is stored off-site.
If the staging test reveals problems, you have time to investigate before touching the live site. You can search for plugin compatibility issues, roll back the update in staging, or reach out to the plugin developer.
Automating backup jobs on a server
For websites hosted on a VPS or dedicated server, relying on a plugin alone can create a single point of failure. If the website is compromised or the plugin fails, automated backups may stop running without anyone noticing.
Setting up a server-level backup script that runs independently of the website gives you a more reliable process. A simple approach uses a cron job to run mysqldump for the database and tar for files, then copies the resulting archive to cloud storage.
# Example cron entry for daily database backup at 3am
0 3 * * * mysqldump -u dbuser -pPassword database_name | gzip > /backups/db_$(date +\%Y\%m\%d).sql.gzThe cron job runs at the server level, outside the website context. Even if the website goes down, the database backup script continues to run. Adding a separate script to sync backup archives to cloud storage completes the off-site requirement.
For WordPress specifically, the official backup documentation covers some core concepts worth reviewing, though most production backup strategies go beyond what is described there. You can find the WordPress backup documentation useful for understanding what WordPress itself considers essential.
Common backup mistakes that cause problems
Knowing what goes wrong in practice helps avoid the same problems. These are the mistakes I see most often with small business website backups.
Backing up without excluding temporary files. Including cache directories, session files, or temporary upload folders inflates backup size and can cause restore issues if those directories have inconsistent states. Configure your backup process to exclude directories that are regenerated automatically.
Storing backups in the public web directory. If backup archives are accessible via a URL on the same domain, they can be downloaded by anyone who finds the link. Store backups outside the web root or in a location with proper access controls.
Relying on a single backup solution. If one plugin fails or one storage service goes down, a single point of failure means no backup. Use a combination of local and off-site storage.
Not testing after server changes. Upgrading PHP versions, moving hosting providers, or changing server configurations can break a restore process. Test restores after any significant server change.
Forgetting about backup retention. Keeping too many backups wastes storage. Keeping too few means you may not have a clean version from before a problem started. A common approach is to keep daily backups for the last week, weekly backups for the last month, and monthly backups for longer, deleting older ones automatically.
When to handle backups yourself and when to ask for help
Small business owners who are comfortable with their hosting control panel, a backup plugin, and basic file management can handle most day-to-day backup tasks. The key is setting up the process correctly initially and testing it regularly.
However, if your site is complex, if you are running a custom PHP application, if you have experienced restore failures in the past, or if you do not have time to verify backups consistently, it is worth discussing the setup with someone who manages website infrastructure regularly. A review of your current backup strategy can identify gaps before they become urgent problems.
N. Cristea offers website maintenance support that includes reviewing backup configurations, testing restore processes, and setting up automated backup jobs for WordPress and custom PHP sites. If your current setup has not been tested recently, that is a practical place to start.