Table of Contents
Purpose of `/var`
The /var directory holds data that changes while the system is running. Unlike directories such as /usr, which mostly contain static programs and libraries, /var is intended for files that grow, shrink, or are frequently modified. This includes logs, queues, caches, and various run‑time data used by services and applications.
On a typical system, the size of /var increases over time. Services write logs, caches are created, and background tasks generate files that live here. When planning disk space or troubleshooting a full filesystem, understanding what lives under /var is very important.
Key idea: /var contains variable data that changes during normal system operation, such as logs, caches, spools, and databases. If /var fills up, system services may fail or behave unpredictably.
Typical contents of `/var`
Inside /var you will usually find a set of standard subdirectories. Their exact usage and presence can differ slightly between distributions, but the general ideas are the same.
A very common subdirectory is /var/log. System services, applications, and the kernel write messages here. These log files record events such as system startup, authentication attempts, package installations, and service failures. When you investigate problems or security issues, /var/log is often the first place you inspect.
You will also find /var/cache. This holds cached data that can be regenerated if needed. For example, package managers store downloaded package files and metadata here so that repeated operations are faster and do not always require fresh downloads. If disk space is low, clearing appropriate caches under /var/cache is often safe, because the system can recreate them. The exact cache layout and cleanup tools depend on your distribution.
Another important directory is /var/spool. A spool directory is used for tasks that are queued for later processing. Traditional examples are print jobs and mail queues. A printing system may store incoming print jobs in /var/spool until the printer is ready. Similarly, a mail server can keep outgoing messages in a spool directory until they are delivered.
Temporary and lock data related to long‑running services often lives in /var/lib. This directory holds persistent state for applications. For example, some databases, web servers, or package managers keep their data, state files, or internal databases under /var/lib. Unlike cache data, information in /var/lib is usually not safe to delete if you want services to keep working and to preserve their configuration and content.
You may also see /var/run on older systems, or more commonly a symbolic link from /var/run to /run. This holds information about processes and services that are running on the system, such as process identifiers and sockets. It reflects the current state of the system rather than long‑term data.
Finally, /var/tmp provides a place for temporary files that must survive a reboot. This is different from /tmp, which is often cleaned at boot time or more aggressively. Applications that need to keep temporary state between reboots may use /var/tmp for that purpose.
`/var` and system services
Many system services depend on /var to operate correctly. For example, a web server might log requests to /var/log, store its runtime data in /var/lib, and use /var/cache for cached content. A mail server will usually maintain its queues in /var/spool and logs in /var/log. Package managers use /var/lib to track what is installed and /var/cache to store downloaded packages.
Because so many services rely on it, if the filesystem containing /var becomes full or corrupted, normal system operation can be severely affected. Logs might stop updating, services might fail to start because they cannot create required files, and queued tasks might not be processed. System administrators therefore monitor available space in /var and sometimes place it on a separate partition to limit the impact of growth in this directory.
Managing growth in `/var`
Since the content of /var changes and can grow indefinitely, managing it is part of routine system care. Log files in /var/log are often rotated, compressed, and removed after some time. Tools dedicated to log rotation read configuration files to decide how frequently to rotate logs and how many old versions to keep. This keeps log directories from consuming all available space while still preserving useful history.
Caches under /var/cache can be cleaned when space is tight. Distributions usually provide package manager commands or dedicated cleanup tools for this purpose. It is important to distinguish between caches that are safe to delete and application data under /var/lib and /var/spool that you must keep if you want services to continue functioning or to preserve user data.
Temporary files that accumulate in /var/tmp can also be managed by system tools or manually, depending on system policies. Unlike /tmp, automatic cleanup of /var/tmp is usually more conservative, to avoid removing files that applications expect to persist across reboots.
`/var` and backups
Because /var holds both expendable data and critical state, it requires some thought during backups. Certain parts of /var, for example /var/log or /var/cache, may not always need full or frequent backups, depending on how you value that data and how long you want to keep it.
In contrast, many directories under /var/lib and /var/spool contain important information such as databases, mail queues, or application state. Losing this data can mean losing messages, content, or configuration that exists nowhere else. Backup strategies often treat these areas carefully and may coordinate backups with service downtime or special snapshot features to avoid inconsistent copies.
Understanding which areas of /var are essential and which areas are disposable helps design an efficient backup policy that protects important information without wasting storage on data that is easy to recreate.