Monitor Linux VPS disk space before it fills up

A nearly full disk can interrupt a database, block an update, or stop a Linux VPS from writing its logs. The right approach is to monitor the available space, locate the directories that are growing, and set up an alert before the disk fills up. This guide describes a simple routine that works on an Ubuntu server or any other Linux distribution using standard commands.

Spotting the available disk space

Start by checking the usage of each filesystem with df -h. The -h option makes the sizes readable and lets you quickly compare total space, used space, and remaining space. Pay particular attention to the used-percentage column and to the relevant mount point.

df -h

The root partition, shown as /, often holds the logs, temporary files, and part of the application data. Reaching 80% does not yet mean an outage, but it should trigger a check. At 90% or more, reduce the risk without waiting: find the cause, verify the backups, and plan a documented extension or cleanup.

To also check for files that can use up inodes without consuming many gigabytes, run:

df -ih

Running out of inodes can produce behavior similar to a full partition. This situation typically appears with a very large number of small files, caches, or poorly cleaned temporary files.

Identifying the responsible directories

The du command helps you move from the overall view to the concrete cause. From the root, this version lists the main directories without descending into other filesystems:

sudo du -xhd1 / 2>/dev/null | sort -h

Then locate the large directory and drill down to a more precise level. For example, if /var is significant:

sudo du -xhd1 /var 2>/dev/null | sort -h
sudo du -xhd1 /var/log 2>/dev/null | sort -h

Don't delete a file just because it is large. A file opened by a process can keep occupying space even after it has apparently been deleted. To find deleted-but-still-open files, you can use lsof if the package is installed:

sudo lsof +L1

Before taking any action, note the path, the owner, the modification date, and the service involved. This record keeps you from confusing a normal log, an expected backup, and abnormal growth.

Controlling logs and caches

System logs are useful for diagnosing an incident, but they must follow a retention policy. Check how much space the systemd journal occupies:

journalctl --disk-usage

If a reduction is needed, choose a duration or a size explicitly, then verify the result. For example:

sudo journalctl --vacuum-time=14d
journalctl --disk-usage

This command is not a substitute for a durable configuration. Check the log rotation, the relevant service's configuration files, and the retention rules defined for your use. For packages, a cache can also be inspected before a distribution-appropriate cleanup. Don't manually wipe all of /var/lib: some subdirectories hold persistent data, such as a MySQL database or the files of an Apache web server.

Checking the server remotely

On a VPS administered over SSH, run the diagnostic with an account that has the necessary rights, then use sudo only for protected paths. Don't confuse the disk space of a hard drive or SSD with RAM: df measures filesystems, while memory and CPU must be tracked with separate checks. The operating system, the storage type, and the disk size affect the available margin, not the measurement method.

ssh utilisateur@adresse-ip
hostname
sudo df -h
free -h

This check lets you confirm you're on the right server before a cleanup operation. A check run against the wrong hostname can lead to deleting data on another machine.

Connecting disk, backup, and security

A virtual server may store a local backup, the files of a CMS, PHP scripts, or a database. This data must be kept separate from caches and logs. A local backup does not protect against a failure of the same storage: also check the off-site copy and periodically run a restore test. The word backup must not hide the absence of a test.

Operations run with the root account must be limited and verified. Before deleting a file, confirm the path, the owning user, and the associated service. Also check the firewall and SSH access, because abnormal log growth can signal repeated attempts or a misconfiguration. Bandwidth, processor, and RAM complete the diagnosis, but they do not replace measuring disk space.

Sizing a virtual hosting environment

A VPS is a virtual machine hosted on physical infrastructure. Virtualization makes it easier to evolve an offering, but it does not remove the limit of the disk assigned to your private server. Before choosing hosting, distinguish storage space, processor power, RAM, and bandwidth. A website with a CMS, PHP, and email does not have the same profile as a game server or a database.

A dedicated server provides storage reserved for one physical machine, while a VPS uses a defined share of a shared infrastructure. In both cases, monitoring remains necessary: increasing capacity does not replace log rotation, a verified backup, or a restore procedure. For a growing workload, compare the initial space, the possibility of extension, the backup, and the level of included administration rather than a single figure.

Checking the host's options

Before subscribing, check what the offer actually allows: disk capacity, possibility of extension, root or user access, any control panel, and the level of managed support. Ask how the server is administered, where the backups are stored, and what limits apply to bandwidth. A cloud server or several virtual servers can meet different needs, but monitoring each mount point remains essential.

Don't choose a plan just because it advertises unlimited space without specifying the applicable rules. For a website, a CMS, PHP, MySQL or PostgreSQL, plan for the files, the databases, the logs, and the backup copies. The firewall and network services must also be documented so you can tell a storage problem apart from a security or connectivity problem.

Monitoring growth over time

A one-off check does not let you tell a normal event apart from steady growth. Keep the results of df -h at regular intervals and compare the partition, the used percentage, and the available space. You can start with a daily check, then adjust the frequency according to the role of the VPS.

A useful alert must state the server, the mount point, the observed percentage, and the date. It must also avoid endless repetitions. Define an alert threshold and a return-to-normal threshold, so you don't send a message for every minor variation.

For more complete monitoring, combine disk space with other signals: load, memory, service status, and backup results. A free disk does not on its own guarantee that an application is working correctly.

Avoiding VPS saturation

• Keep a margin of space for updates, logs, and temporary files.
• Identify the persistent-data directories before planning an extension.
• Define the retention of logs and backups, then verify it periodically.
• Test restoring a backup separately from checking disk space.
• Document every file deletion or move and keep a rollback procedure.

If consumption increases despite correct rotation, look for the application-level cause: a logging loop, undeleted temporary files, too many local backups, forgotten containers, or downloads. Cleaning up without fixing the cause only postpones the next alert.

Choosing the right capacity

The capacity you need depends on the data, the logs, the backups, and the expected growth. A game server, a database, and a web service do not have the same profile. Estimate current consumption, measure its progression, and add a margin for exceptional operations before choosing a plan or an extension.

To compare the available environments, see our dedicated pages for Linux VPS, Ubuntu VPS, and dedicated servers. If your workload uses Docker, you can also read our guide on installing Docker on a VPS and check the space occupied by images, volumes, and logs.