Linux Server Monthly Maintenance Checklist

A Linux server that’s well-configured from the start can run for months without any noticeable issues, and all the services on it can operate quite normally. Websites load, the database responds, SSH is available, and there don’t seem to be any problems. Meanwhile, the size of the server’s logs is constantly growing, updates are piling up, inodes are running out, old and outdated SSH keys remain, and so on and so forth. In other words, over time, your server will inevitably become cluttered.

Therefore, it’s a good idea to go through the server about once a month and evaluate its performance - from the overall system health to applications and backups. Ideally, such a check shouldn’t turn into a multi-hour audit; that is, all steps should be simple and straightforward, while the result should be clear and predictable.

We thought this would be helpful for our readers, so we decided to briefly describe the sequence of actions and commands you can use for a monthly audit of your VPS, dedicated server, or even a small production infrastructure. Let’s get started.

 

 

 

 

Step 1. Check the server’s current status

As with any task, it’s best to start by getting a big-picture view before rushing to update anything or restart services. To do this, use the following set of standard commands:

uptime
free -h
df -h
df -i
systemctl --failed
timedatectl

Here, we’re primarily interested in load, memory and swap, free disk space, inodes, failed systemd units, and the accuracy of the system time.

There is, however, a nuance with the numbers. For example, used RAM alone doesn’t tell us much, since Linux actively uses memory for caching. It’s much more useful to compare the current state with the typical state of this specific server.

The same goes for disk space. For example, the /vardirectory, which consistently takes up 70 GB, may be perfectly normal. But if its size increases from 35 to 70 GB over a couple of months - that’s a reason to investigate.

 

 

 

 

Step 2. Let’s see what happened over the past month

When we look at the server’s current state, it tells us nothing about the system’s condition - even in the recent past. After all, the server might have been experiencing some issues a couple of weeks ago but now appear completely healthy. Therefore, a mandatory step in such an audit is to check the server’s main logs for unusual events in the past:

journalctl -p warning..alert --since "30 days ago"
journalctl -k -p warning..alert --since "30 days ago"

 

And separately, let’s look for OOM (Out Of Memory) events:

journalctl -k --since "30 days ago" | grep -Ei ‘oom|out of memory|killed process’

 

Recurring errors are much more important and revealing than a single entry, especially if they involve disk, file system, or network issues, or a service that crashes regularly.

OOM errors are also easy to miss, since the server might have several gigabytes of free RAM today, even though a week ago the kernel, for example, terminated PostgreSQL or PHP-FPM due to a lack of memory.

 

 

 

 

Step 3. Check for Updates

Updates for Linux distributions are released constantly. They fix identified bugs, patch discovered vulnerabilities, and update system libraries and individual system components. On a server that’s been running for a long time, some of these packages may remain in their old versions for months, especially if automatic updates haven’t been configured.

Therefore, during monthly maintenance, it’s worth checking which updates are available. It’s not necessary to install everything right away; first, review the list of suggested packages to understand exactly what will change.

For Debian and Ubuntu, this can be done with the following commands:

apt update
apt list --upgradable

 

For RHEL-like systems:

dnf check-update

 

First and foremost, in the resulting list, you should pay attention to the kernel, OpenSSH, system libraries, the database management system, the web server, and software that accepts connections from the Internet, since vulnerabilities are most often found in those areas.

Of course, critical security updates should be installed immediately after they are released, without waiting for scheduled maintenance. During this monthly check, it’s sufficient to simply see which updates have accumulated since the last time and which ones need to be installed.

 

After installing packages in Debian and Ubuntu, check whether a reboot is required:

test -f /var/run/reboot-required && cat /var/run/reboot-required

 

You can check the current kernel separately using the command:

uname -r

 

It’s helpful to do this after updating kernel packages, since the new kernel may already be on the disk, but the server will continue to run on the old version until a reboot - which isn’t exactly what we’re aiming for.

 

 

 

 

Step 4. Check the Disks and Logs

Disk space on the server is constantly being used up, as system logs grow continuously, applications create temporary files, old packages and kernels remain after updates, and so on. And if your server’s free disk space runs out, problems can arise across several service types at once - from the database to the web server. Therefore, during your monthly check, it’s helpful to see which directories are growing faster than usual and how much space the logs are taking up. And, if necessary, clean them up.

Now let’s figure out exactly where the space is going.

du -xhd1 /var | sort -h
journalctl --disk-usage

 

If /var/loghas grown, take a closer look inside that directory:

du -xhd1 /var/log | sort -h

 

If you find a large log file, don’t rush to delete it. First, locate the source that’s writing to that log and figure out why the application is writing so much data and whether log rotation is working.

While you’re at it, check the /boot directory, old archives, temporary files, and the settings for the logrotate utility, which we highly recommend using.

 

To learn how to install and configure it, read this article.

Also, when analyzing logs, keep in mind that the du commandmay not display files that appear to have been deleted but are still being kept open by some process. As a result, disk space remains occupied. It’s best to view such files using the command:

lsof +L1

If you find a huge deleted file there, try to locate the process holding it open and restart it using standard methods.

 

 

 

 

Step 5. Checking Background Tasks

Many routine operations on the server are performed automatically and typically do not require the administrator’s attention. Tasks such as backups, certificate renewals, cleaning up temporary files, and various maintenance scripts can run on schedule for months without drawing much attention. Problems can arise if one of these tasks stops running for some reason, and there are no noticeable consequences at first.

To check scheduled tasks (systemd timers), use the following command:

systemctl list-timers --all

 

Check the time of the last run for important tasks and the date of the next run; if a task hasn’t run in a long time or has an unusual schedule, you should definitely check the corresponding service and its log.

For cron, check the jobs themselves and verify their actual execution using the logs. It’s worth paying special attention to backups, automated maintenance scripts, and other tasks on which the server’s operation depends.

Just remember that the mere presence of a specific line in the crontab doesn’t necessarily mean the script runs successfully - it might terminate with an error, lack the necessary permissions, or attempt to access an unavailable file, causing it to crash. That’s why we’re specifically interested in the result of the task’s most recent execution. By the way, we have a separate brief article on configuring cron.

 

 

 

 

Step 6. Perform a Quick Security Audit

Even if the server is running stably, it’s still a good idea to check once a month who has access to it and which services are accessible from the network. Over time, old accounts, forgotten SSH keys, or open ports that are no longer needed may remain. Of course, conducting a full system security audit every month is excessive. But for a simple monthly check, a couple of standard commands are enough:

last
ss -lntup
getent group sudo

These commands will display information about:

• recent logins and unknown connections;
• users with administrative privileges;
• old accounts and SSH keys;
• open ports;
• firewall rules - UFW, firewalld, or nftables.

 

Be sure to cross-check the list of open ports against the services that are actually supposed to be accessible on this server. If you happen to discover an unfamiliar port or user, first determine where it came from and whether it’s currently needed.

It’s especially helpful to review access permissions after contractors or temporary employees have finished their work, since an old SSH key can easily outlive the person to whom it was originally issued.

And of course, if you uncover any suspicious "clues" during this basic check, you must conduct a full-scale server security audit to eliminate the possibility of system compromise.

 

 

 

 

Step 7. Checking Applications

The Linux system itself is merely an operating system and may well be functioning normally, while the problem lies at the level of a particular application.

For Nginx or Apache web servers, be sure to review the error log and examine the configuration files. For PostgreSQL or MariaDB databases, check the service status, errors, data size, and available disk space. The specific set of checks obviously depends on the server’s end-use and, consequently, on the software installed.

For example, if you’re using Docker, you should review the list of stopped containers and disk space usage:

docker ps -a
docker system df

However, automatically running docker system prune -a on a schedule is a bad and destructive habit, because you first need to determine which data is truly no longer needed and only then delete it. And when working with volumes, you need to be especially careful.

 

Checking TLS

Certificates of all kinds are in a class of their own. Even with automatic certificate renewal, it’s useful to occasionally check what the server is actually sending to the client. To do this, use a command like this:

echo | openssl s_client -connect example.com:443 \
-servername example.com 2>/dev/null | \
openssl x509 -noout -dates

This verifies the certificate that is currently active, since the file on the disk may have been updated, but the web server might, for some reason, continue to use the old certificate.

However, it’s better to incorporate certificate expiration checks into your monitoring system and set up notifications so you can identify the issue in advance and update the certificates before the website becomes inaccessible.

 

 

 

 

Step 8. Checking Backups

Backing up data only makes sense if the data can actually be restored from the backup. This idea seems obvious, but very often administrators simply pile backups "into a heap", and when the need arises to urgently restore data from a backup - it simply can’t be done for one reason or another, whether due to incompatible file formats or issues with the process itself. Therefore, a "green" status for the latest backup is only half the check.

The best solution is to take a real backup once a month and try to restore it in an isolated environment, such as a temporary virtual machine, a test VPS, or a separate disk.

After restoration, check the data and database, file permissions and owners, and whether services are running. Also check the date of the restored data, as a usable backup may unexpectedly turn out to be much older than expected.

Also, check the last few backup jobs. If one of the jobs completed with an error or took noticeably longer than usual, you should immediately investigate the cause.

Check the backup storage as well, since free space there also tends to run out, and an overfilled storage will eventually stop accepting new backups.

 

 

 

 

Step 9. Summarizing the Check

After this basic monthly maintenance, be sure to document the server’s current status. You don’t need a detailed report - simply note a few metrics and any issues found so you have something to compare against during the next check.

 

The monthly check itself can be broken down into the following steps:

1. Check the load average, RAM, swap, disks, and inodes;
2. Review failed units and system errors for the month;
3. Identify OOM and other critical events;
4. Check for updates, the kernel, and whether a reboot is needed;
5. Review the status of /var, /var/log, /boot, and the journal;
6. Check cron, systemd timers, and log rotation;
7. Review users, SSH keys, ports, and the firewall;
8. Check applications, Docker, and databases;
9. Check TLS certificates;
10. Review backup results and perform a test restore;
11. Record any anomalies found.

 

To document and track the history of these checks, a simple table in any format will suffice, such as:

Metric	August	September
/var	48 GB	61 GB
Backup storage	54%	67%
Failed units	0	0
OOM events	0	2

This type of record helps you see changes over time that are hard to spot during a one-time check. For example, 61 GB used in /var doesn’t mean much on its own. But an increase in this metric from 48 to 61 GB over the course of a month warrants close attention. The same applies to the occurrence of OOM events or rapid filling of the backup storage.

It’s also worth keeping in mind that some of the most critical and important metrics are best included in continuous monitoring with alerts.

That said, periodic manual checks are still useful. Monitoring, for example, will report that the /var directory is growing rapidly, and the administrator can then investigate the cause of this rapid growth. Or, for example, the backup system might show that a job has completed successfully, while a test restore will confirm that the saved data can indeed be used in an emergency.

 

In summary, it’s worth noting that monthly maintenance of a Linux server doesn’t require much time or effort if you follow a clear checklist. And the results will be clear if you keep a record of your checks, even in a simple, informal format. Regularly checking the system’s status, updates, disks, background tasks, security, and backups helps you spot minor issues before they start interfering with your server’s operation.

 

 

FAQ or Frequently Asked Questions

 

How often should you check a Linux server?

For a small VPS or a standalone server, a thorough manual check once a month is usually sufficient. However, it’s best to continuously monitor disk health, service availability, backup errors, and other critical events using monitoring tools.

 

Do I need to reboot the server every month?

No. There’s no point in rebooting the server just on a schedule. This is usually done after updating the kernel or other system components that require a reboot for the changes to take effect. Long uptime isn’t a problem in and of itself.

 

Do you need to manually clean up logs?

Usually not. logrotate, systemd-journald, or the application itself is responsible for rotating and deleting old logs. If a log suddenly grows to several gigabytes, first determine the cause. Simply deleting the file will free up space, but the problem will soon reappear.

 

How do you verify a backup?

The most reliable option is to restore it in an isolated environment and verify the data, the database, access permissions, and application startup. Successfully creating a backup does not guarantee that you’ll be able to restore a working server from it.

 

What should you do if the server is running out of space?

First, identify which partition and which directories are growing. Often, the culprits are logs, temporary files, old archives, Docker data, or accumulated backups. You shouldn’t blindly delete the largest files - first, you need to understand why they’re needed and which process creates them.

 

What kinds of issues can be detected during a monthly check?

Most often, you’ll find things that aren’t yet interfering with the server’s operation: accumulated updates, growing logs, background task errors, old SSH keys, or a lack of space in backup storage. This is exactly why such a check is needed - to address these issues before they have noticeable consequences.

 

Which parts of the monthly check should be automated?

First and foremost: monitoring free disk space, load and memory usage, service availability, backup errors, OOM (Out of Memory) errors, and the expiration dates of TLS certificates. If a problem requires an immediate response upon detection, there’s no point in waiting for the next manual check.