Like a home or a car, a virtual private server (VPS) works best when it’s maintained both thoroughly and thoughtfully. We get a lot of questions from our users about how they should be maintaining their servers, and so we thought it was time to put together a checklist of key tips.
These tips aren’t necessarily in order of importance— there are too many variables to say this one maintenance tip is most important for all servers. This checklist should be just one guiding pillar of your overall maintenance plan.
It’s also important to mention that these are general tips that should work for most deployments. If you’re running an application you’ve built yourself, you’ll need to find and follow additional maintenance tips. This also applies if you’re running a complex infrastructure like a self-hosted Docker setup or Linux containers.
How often should you be maintaining your VPS?
This is another question we hear often. Again, the maintenance schedule depends quite a bit on what applications you’re running, how important they are to you, and how much time and effort you can devote to server maintenance.
To help answer some of those questions, I’ve organized the checklist into weekly, monthly, and semi-annually groups.
Weekly
Review your memory/CPU utilization
Your server’s performance is entirely dependent on resource utilization. If you’re running low on RAM, for example, your operating system will begin killing programs until it fixes the problem. That could include an essential part of your service.
Most hosting companies offer a dashboard that allows you to see resource usage over a certain period. This will help you understand, at a glance, whether anything weird is happening on your VPS. With SSD Nodes, you can see this information in your client area. Just click on the server you’re interested in, and then find the “Usage Statistics” link.
A more direct way to examine live resource utilization is to use a monitoring program like top or htop. To use these, SSH into your server and run them (after installing them via your package manager, if necessary). Be sure to check out our quick tip on maximizing top for more information. top and htop will tell you if any specific programs are using too much RAM or CPU.
If resources have spiked unexpectedly (or dropped, for that matter), you’ll know that something has gone awry. Time to spend some time in the terminal figuring out what’s gone wrong, and what to do about it.
Check in on disk space
If you’re running any database on your server and it runs out of disk space, bad things start to happen. We’re talking unresponsiveness, corrupted data, and more.
Fortunately, checking in on disk space is pretty easy. A simple df run will help you see which partitions are filling up, and how much space is left.
If you’re nearly out of space, here’s one trick to perhaps clear out some space: Delete your package manager’s cache.
Ubuntu/Debian:
$ sudo apt-get cleanCentOS
$ sudo yum clean allIf that doesn’t help, you may have to hone in on your own files, as Linux installations are pretty bare bones.
Review logins and user accounts
You can see precisely who is currently logged in using w. The last command will list every recent login, and the lastlog command will tell you exactly when each user last logged into the VPS. Generally, these commands parse access log files into a more human-readable format.
You can use these commands together to understand precisely when—or how—someone might have accessed your VPS. If you see that an unexpected IP address has logged into your VPS using your user, you’ll know that your server has been compromised.
Sadly, in this case, it’s most likely time to reinstall your operating system and rebuild your infrastructure using a clean slate. With an eye toward security—key-based SSH logins are a good start.
Check other access/error logs
Most VPS applications/services create a log of events and errors that can be read and analyzed at a later time. These logs offer a wealth of information about the general health of your services and should be looked at fairly frequently.
You probably won’t have all of them, but here are a few common log files to check out:
# Apache
$ sudo tail -f /var/log/apache2/error.log
$ sudo tail -f /var/log/apache2/access.log
# Nginx
$ sudo tail -f /var/log/nginx/error.log
$ sudo tail -f /var/log/nginx/access.log
# Mail
$ sudo tail -f /var/log/mail.log
# MySQL
$ sudo tail -f /var/log/mysql/error.log
# System log
$ sudo tail -f /var/log/syslog
$ sudo tail -f /var/log/messagesIf you want more ideas on how to best read/parse these logs, here’s a good guide on using awk to get insights on Nginx response codes. Just adapt to your own needs.
Update your operating system (particularly security packages)
Most Linux distributions update fairly regularly. Of the three operating systems we offer—Ubuntu, Debian, and CentOS—Ubuntu changes most often, with Debian and CentOS favoring a more conservative approach to adopting new software versions across the board.
But all three operating system development teams are quick to release patches for known security flaws.
By not regularly updating your operating system’s packages, you could be leaving your VPS vulnerable to attackers. Luckily, upgrades are quite easy on these systems!
Ubuntu/Debian:
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get cleanCentOS
$ sudo clean all
$ sudo yum updateUpdate your services (like WordPress)
Updating packages from your operating system’s repositories, as in the tip above, will ensure a lot of software stays up-to-date, but they don’t cover everything. If you’ve installed software by any means other than the apt-get/yum command, it needs to be updated separately.
A good example is WordPress or any other content management system you might have installed. Or, pretty much anything you installed via our tutorials.
You should read the documentation for each of these services and make sure you’re updating them regularly. Some have graphical/dashboard interfaces for updates, and some will require you to spend some time on the terminal.
When updating your services, don’t forget about anything else you’ve installed on top of them, such as plug-ins for a WordPress blog. Most of the vulnerabilities to WordPress blogs come from outdated or poorly-coded plug-ins. At this point, the WordPress codebase is pretty secure, but they don’t make guarantees about any plug-in. And some of them are written by people who, simply put, shouldn’t be writing code that gets executed on other people’s servers.
Monthly
Verify your backup system is working
Or set one up if you haven’t already!
I can’t say which backup system/plan is best for you, but we have outlined one simple backup method that you may be able to adapt to your own needs. Generally speaking, most simple backup systems involve rsync or another program that synchronizes files from your server to another physical location and disk.
Simply copying files from one part of your VPS to another is not a backup!
Take your backup plan to the automated level by using cron to schedule them at an interval you think best. Businesses that retain customer data, like those running a SaaS app, will be deploying backups very frequently, as in daily or even more frequent. If you have a blog you only update once every few months, a monthly backup might be enough.
Remember that you don’t have a backup plan unless it’s automated and you know it’s working. If you dump your files somewhere but don’t know how to restore them and get your VPS up and running again, it’s not a backup. It’s just a bunch of files.
Take the time to check that your server’s files are being accurately replicated at the backup destination. Nothing is worse than trying to recover from a catastrophe, only to realize your backup system fell through six weeks ago.
Ensure your services can gracefully handle shutdowns/downtime
This one is a little more advanced, but essential for anyone running a service on their VPS that’s meaningful to them. A business website would be a good example, or a self-hosted email solution — basically, anything you wouldn’t want to go offline for more than a few minutes.
Let’s say there’s a rare unplanned downtime at the data center in which your server is hosted. Your server is forced to shut down during the maintenance. When things are fixed your server boots up. Do you know if your services will start back up again, and work properly, without your manual intervention?
If you can’t answer that question definitively, you should take time to ensure your services can auto-start on boot. If things don’t bounce back correctly, look into the logs for each critical service and see why they’re not starting automatically.
Our operating system templates now use Systemd and its systemctl command to manage services and daemons in various ways, such as starting them automatically on boot. Systemd, systemctl, and journalctl should be able to help.
Semi-annually
Set up automatic updates and check they’re being installed
If you’d prefer not to worry about updating your VPS regularly, you can set up automatic updates. The pro of automatic updates is that it’s one less thing to forget about, and the con is that you a bit of control—if an updated package sends your server into a frenzy, it’ll be harder to track down the offending package.
For details on enabling automatic updates, check out these three guides:
Change up passwords
There’s a lot of debate about whether or not forcing password changes is a smart security decision. The more passwords people have to remember, the more likely they are to write them down or use insecure ones. For IT teams, this is a real concern.
But, if you’re the only one accessing your VPS, password changes should be easy to manage and improve your security quite a bit.
It’s pretty easy to force password changes after a certain number of days, or hop in there every once in a while and fire off a passwd command to change your user’s password (and thus the one you use to run commands with sudo).
Shut down/uninstall unused services
A lot of our customers use their VPS as an educational platform or a testbed for new ideas. They often end up with one service they care about and a half-dozen others they don’t need anymore.
I highly recommend taking time every few months to prune your system of any unused service. Every addition you make adds a potential attack vector, especially if you leave them to get out-of-date and vulnerable to security attacks.
You’ll have to prune the way you installed, either via your package manager or the service’s documentation. When uninstalling packages via your distribution’s package manager, take care that you’re not also uninstalling any dependencies for a service you do want to continue running. Package managers tend to be smart about these things, but it never hurts to double-check.
Run a security audit
Lynis is a security auditing for systems based on UNIX like Linux, macOS, BSD, and others. It performs an in-depth security scan and runs on the system itself. The primary goal is to test security defenses and provide tips for further system hardening. It will also scan for general system information, vulnerable software packages, and possible configuration issues.
Sound like something you could benefit from? Lynis will help you scan your system for security issues, and I recommend you run it on a somewhat frequent basis. If you follow its recommendations, you’ll get less output over time, but Lynis could help reveal a new security issue you weren’t previously aware of.
We even have a tutorial on using Lynis on a VPS.
Next up: Customizing and expanding your checklist
Following this 12-point checklist might seem like a lot of work, but most of the steps are quick to execute, and you’ll get more efficient with practice.
The last tip I’d like to leave you with is to adopt the checklist to your own needs. You might have different timeframes, you might be able to cut certain points, and you might need to add your own. A customized checklist is the one you’ll follow best—I hope you take the opportunity while your server is still running great.
