So you’ve followed our in-depth guide and built yourself a shiny new server that’s secure and tuned for optimal WordPress performance, but what’s next? In this installment of Hosting WordPress Yourself, I’m going to outline a few tasks that should be carried out on a regular basis to ensure that your server continues to run securely and perform well. We’ll look at performing software updates, upgrading PHP, and a few “gotchas” to watch out for that we may have experienced ourselves. Let’s dive straight in!
Keep Plugins and Themes Updated
Let’s start with an easy one that isn’t just applicable to self-hosted WordPress installs. WordPress itself, WordPress themes, and all plugins should be regularly updated. No software is immune to vulnerabilities and updating often will ensure those inevitable vulnerabilities are patched.
While you’re at it, make sure you delete obsolete themes and plugins. There’s no reason to keep them around, other than to provide a potential entry point for malicious users. The majority of premium plugins and themes won’t receive updates via the WordPress dashboard if they’re deactivated. For that reason, it’s better to delete them than leave them lying around.
Check Backups are Running
It’s inevitable that things go wrong, sometimes horribly. Regular full-site backups are an integral part of any disaster recovery process. In part 5 of this series, I demonstrated how to set them up. However, you need to ensure that they are running as expected months down the line.
Earlier this year, Brad noticed that our site backups hadn’t made it to S3 for almost two months. The cause? Our backup script had stopped working due to a Python dependency issue. The moral of the story? Check that backups are being carried out on a regular basis before it’s too late! You should also periodically test the backups by importing the SQL into a test database to ensure they’re usable if things were to go wrong.
Keep an Eye on Server Metrics
If you haven’t already configured some form of server monitoring, then go do so now! You should also ensure that you have alerts configured for CPU, memory and disk utilization because they can help clue you in to potential bigger problems.
High resource usage can be the first sign that something is wrong with your server or the applications that it’s running. Recently, we were receiving high CPU alerts from our VPS provider for this site, deliciousbrains.com. After performing some application monitoring using New Relic, we discovered that a database query was running slow, which was causing MySQL to spike CPU usage. As it turns out, we were missing an index on one of our database tables. The result?
CPU usage dropped considerably. Without server monitoring, it would have been tough to know that there was a problem, let alone deploy a fix.
Watch Those Log Files
Just like server monitoring, log files can help to identify issues early on before they become catastrophic. Every once in a while it’s worth checking the logs to see if anything unusual is happening. I would concentrate on the following:
- Nginx error logs
- PHP error logs
- WordPress debug.log file
We use Papertrail to make it easier to monitor those log files (especially debug.log, which we have permanently enabled). What makes Papertrail ideal is that you can easily send certain logs to Slack. We have an alert configured for any fatal errors that occur.
However, the log files themselves can become problematic if left unchecked. One downside to most VPS providers is that they provide very little disk space, which means the logs can quickly fill the server’s storage.
In the past, I’ve had a server completely fall over because a log file grew to over 25 GBs in size. If I’d have configured server monitoring and periodically checked the logs, this wouldn’t have been a problem. It’s also worth enabling log rotation for log files in custom locations such as debug.log.
Update Server Packages
If you followed along with Hosting WordPress Yourself, you would have configured automatic security updates using
unattended-upgrades, which will apply security updates on a daily basis. However, it won’t install general software updates that contain just bug fixes. If you SSH to your server you’ll often be presented with the following:
Those packages won’t automatically get updated because they don’t contain security fixes. To update them, run:
sudo apt-get update sudo apt-get dist-upgrade
I recommend using
apt-get dist-upgrade vs.
apt-get upgrade because the former will intelligently handle dependencies.
Before performing any upgrades, you should create a full system backup via your VPS provider (sometimes called snapshots).
The previous step will update PHP through the point releases (7.1.18 to 7.1.19), but it won’t upgrade PHP to a new major version such as 7.2. Luckily, it’s a simple process and possible with little to no downtime.
If you are using the
ppa:ondrej/php repository, you can safely install multiple major versions of PHP side-by-side, which we can use to our advantage. Remember that you only need to follow these steps if your server isn’t already running PHP 7.2, otherwise just run
sudo apt-get update sudo apt-get install php7.2-fpm php7.2-common php7.2-mysql php7.2-xml php7.2-xmlrpc php7.2-curl php7.2-gd php7.2-imagick php7.2-cli php7.2-dev php7.2-imap php7.2-mbstring php7.2-opcache php7.2-redis php7.2-soap php7.2-zip -y
Next, you should configure the new version of PHP as demonstrated in part 2. Remember to also copy any modifications from your existing php.ini file, found at
At this point, you’ll have multiple PHP versions installed, but Nginx will still pass requests to the older version. Next, update your site’s Nginx config so that the
fastcgi_pass directive passes requests to PHP 7.2.
Test that your config changes are correct, then restart Nginx.
sudo nginx -t sudo service nginx reload
To ensure that the site is now running on PHP 7.2 you can install the Display PHP Version plugin. Once confirmed, repeat the changes for each site on the server. Ideally, you’ll perform these changes on a staging site and test the critical paths before updating any production sites.
Once you’re happy that everything is working as expected you can remove the old version, like so:
sudo apt-get purge php7.1-*
What About Updating Ubuntu?
We’ve talked about updating packages installed on the server, but what about the server itself? Ubuntu releases a new LTS version every two years, the most recent of which being 18.04 (Bionic Beaver). So should you update to a new LTS version as they’re released? It’s a question often debated, and you’ll get different recommendations depending on who you ask. Personally, I don’t ever upgrade a server’s operating system (OS) and here’s why:
An OS upgrade can be a slow process to complete (think about the last time you updated your computer to a new major release of macOS, Windows, or Linux). During this time your sites will be completely inaccessible. There’s also a good chance that some existing server packages won’t be compatible with your new OS version, which can further increase the downtime as you scamper to rectify such issues.
A much safer approach is to spin up a fresh server. Doing so allows you to test that everything is working as expected fully. A clean slate is also an excellent opportunity to re-assess if your current setup still meets your needs or if a different server stack might be more suitable. You can safely try these changes without impacting your live sites. Once you’re happy with the new setup, you can switch your DNS over with minimal downtime. We’ve been working hard on a solution for making it super easy to provision new servers tuned for hosting WordPress, check it out here.
I’ve covered the various tasks that should be carried out on your server, but how regular should these tasks be performed? I would recommend that you perform the following once a month, which shouldn’t take more than 30 minutes:
- Perform WordPress updates, including themes and plugins
- Ensure backups are running and that they’re usable
- Check your server metrics to see if there were any unusual spikes
- Quickly scan your server’s error logs for problems
- Update server packages
As for upgrading to a new version of Ubuntu, it’s entirely up to you, but don’t stick around past the current version’s end of life date. Here at Delicious Brains, we provision a fresh server roughly every two years, generally after a new LTS release.
What regular server maintenance do you perform? Anything I’ve missed in the above? Let us know in the comments. Happy hosting!