I believe there’s no need to explain why we need proper automated backup solutions for our web servers! When it comes to WordPress, there are plenty of options. Many popular solutions involve installing plugins on WordPress that rely on WordPress cron jobs (WP-Cron) to run automatically. These plugins bundle the website files and dump the database tables using PHP capabilities.
While these plugin-based solutions work well enough in most scenarios, I’ve noticed several important limitations:
- Backing up an application through the application itself is inherently risky! If something goes wrong with WordPress, the plugin, or the web server running them, the entire backup process fails.
- The process heavily relies on PHP and the web server’s limits, timeouts, and configurations—and a lot can go wrong.
- It consumes significant resources, especially with larger websites containing millions of database records and thousands of files. This can keep your web server busy with backup jobs and prevent it from properly responding to actual user requests.
- These solutions have built-in limitations—for example, you cannot backup the web server or underlying OS configurations.
- To restore these backups, you need to first install and set up a basic WordPress instance, install and configure the backup plugin, and then run the restore process—hoping everything goes smoothly.
- These solutions are limited to only a single website and if you want to properly backup multiple websites on the servers it gets more challenging.
I know there are plenty of out-of-the-box solutions for server-level backups, but why install and configure another potentially bloated application with dozens of features you’ll never use? Instead, let’s create a simple but flexible backup solution tailored specifically for OpenLiteSpeed servers hosting WordPress sites, powered by bash scripts and easily deployable with Ansible (or manually)!
Although we’re focusing on OpenLiteSpeed and MariaDB here, with some small tweaks, this solution can be adapted for other web servers like LiteSpeed Enterprise or nginx, and other database systems like MySQL.
In this backup solution I am going to use AWS S3 to store the backups which offers a secure, scalable and relatively cheap remote storage.
In this post I assume you are running a Debian-based Linux distribution on the server (like Debian, Ubuntu, etc). If you are using other Linux distributions, you have to adjust the commands, scripts (and the playbook) accordingly by yourself.
You can find the complete solution including all the scripts and the optional Ansible playbook in this GitHub repository.
Understanding the Backup Requirements
Before diving into our backup solution, let’s understand what we need to back up on a WordPress installation running on an OpenLiteSpeed web server.
What Needs to Be Backed Up?
A complete WordPress backup solution should cover the following critical components:
- Website Files: WordPress core, Themes and plugins,Uploads (images, videos, documents), and in summary whatever we have in the WordPress installation.
- Database Content: All the tables and records in the database being used by WordPress, which includes WP core tables and any possible custom tables created by plugins and themes. Database users and their associated privileges should also be included in the backups with clear mappings showing which user belongs to which database.
- Web Server Configuration: OpenLiteSpeed configuration files, virtual host settings, and SSL certificates need to be backed up to ensure your server configuration can be restored exactly as it was.
- System Configuration: A list of installed packages, cron jobs, and other critical system configurations that make your server environment unique.
A good backup strategy should capture all these components in an automated, scheduled manner, storing output on a remote storage solution securely, while providing a straightforward restoration path.
The bash scripts we’re going to build are designed to achieve all these goals by:
- Automatically detecting websites, databases, and their associated users
- Backing up to a temporary local directory before uploading to a remote storage (AWS S3) and cleaning up the local directory after a successful backup
- Implementing proper error handling and logging throughout the process
- Including a dedicated restoration script that makes recovery simple and reliable