/etc holds the configuration an administrator writes on purpose. /var holds everything the system generates on its own while it runs. The name stands for “variable,” and it is a fitting description: this is the one major top-level directory that grows and changes constantly without anyone directly editing it.

What variable data actually means

Every time a service handles a request, a package installs, a cron job runs, or a user logs in, something typically gets written to /var. This is different in kind from /etc, where content changes only when an administrator deliberately edits a file, or /usr, where content changes only when software is installed or upgraded.

ls /var
# backups  cache  lib  local  lock  log  mail  opt  run  spool  tmp

du -sh /var/* 2>/dev/null | sort -h

The subdirectories that matter most

/var/log/     # log files: system logs, service logs, security logs
/var/cache/   # package manager caches, application caches
/var/lib/     # persistent application state: databases, package metadata
/var/spool/   # queued work: mail spools, print queues, cron spools
/var/mail/    # local mail delivery for user accounts (older systems)
/var/tmp/     # temporary files that should survive a reboot
/var/run/     # runtime data (often a symlink to /run on modern systems)
/var/backups/ # some distributions store automated backup copies here

Each of these serves a distinct purpose, but they share the common trait of growing or changing without direct human intervention.

/var/log in detail

This is the subdirectory administrators interact with most, since it holds the evidence trail for almost everything that happens on the system:

ls /var/log
# syslog       auth.log      nginx/       mysql/
# kern.log     dpkg.log      apt/         journal/

# Tail the main system log live
sudo tail -f /var/log/syslog       # Debian/Ubuntu
sudo journalctl -f                  # systemd-based systems (most modern distros)

# Check authentication attempts and sudo usage
sudo grep sudo /var/log/auth.log
sudo journalctl _COMM=sudo

# Check a specific service's log directory
ls /var/log/nginx/
sudo tail -50 /var/log/nginx/error.log

Modern systemd-based distributions increasingly route logs through the journal (journalctl) rather than flat text files, but /var/log remains where many services, especially third-party software installed outside the package manager, continue to write plain text logs directly.

Why log files do not grow forever

Left unmanaged, a busy web server’s access log or a chatty application’s debug log could consume an entire disk within days. Almost every distribution ships logrotate (or an equivalent) to prevent this:

# View the global logrotate configuration
cat /etc/logrotate.conf

# View per-service rules
ls /etc/logrotate.d/
cat /etc/logrotate.d/nginx

# Manually trigger a rotation to test configuration
sudo logrotate -f /etc/logrotate.d/nginx

# See what rotation produced
ls /var/log/nginx/
# access.log  access.log.1.gz  access.log.2.gz  error.log  error.log.1.gz

A typical logrotate rule rotates a log daily or weekly, compresses the previous version, keeps a set number of historical copies, and deletes anything older than that window. This is why you will often see access.log.1.gz, access.log.2.gz and so on sitting alongside the active log file.

/var/cache and /var/lib

# Package manager cache: downloaded .deb or .rpm files kept for reuse
du -sh /var/cache/apt/archives    # Debian/Ubuntu
du -sh /var/cache/dnf              # Fedora

# Clear the package cache to reclaim space
sudo apt clean                      # Debian/Ubuntu
sudo dnf clean all                  # Fedora

# /var/lib holds actual working data, not just cache
ls /var/lib
# dpkg/  mysql/  postgresql/  docker/  systemd/

The distinction matters when troubleshooting disk space: /var/cache is generally safe to clear because it only holds files that can be re-downloaded if needed, while /var/lib often holds irreplaceable data like an actual database’s tables, so clearing it carelessly can mean permanent data loss.

Why /var sometimes gets its own partition

On servers, especially ones running busy web services, mail servers, or databases, administrators frequently give /var its own dedicated partition:

findmnt /var
df -h /var

The reasoning is straightforward: if a bug causes a service to write gigabytes of logs in a runaway loop, or a mail queue backs up during an outage, that growth fills the /var partition and stops there, rather than consuming the space the root filesystem needs to keep the operating system itself functioning. A full root partition can prevent new processes from starting, stop existing services from writing anything at all, and in the worst case leave a system unable to boot cleanly on the next restart.

Diagnosing a full /var

# Which top-level subdirectory is the biggest?
du -sh /var/* 2>/dev/null | sort -h

# Drill into the usual suspects
du -sh /var/log/* 2>/dev/null | sort -h
du -sh /var/cache/* 2>/dev/null | sort -h

# Find the single largest files anywhere under /var
find /var -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -k5 -h

In practice, /var/log growing unexpectedly is almost always either a misbehaving service logging far more than intended, or a logrotate configuration that was never applied to a newer service, leaving its logs to accumulate without ever being rotated or deleted.

Frequently Asked Questions

What is the /var directory used for?

The name /var stands for “variable,” meaning data that changes during normal system operation as opposed to static program files or fixed configuration. This includes log files, mail spools, package manager caches, print queues, and the working data for many databases and applications. Unlike /etc, which you edit deliberately, the contents of /var are generated and modified automatically by running software.

Why do log files grow so large and where are they stored?

Log files accumulate because services write a new entry every time something noteworthy happens: an HTTP request, a failed login attempt, a service restart, a kernel warning. Over weeks or months on a busy server, this adds up. Most logs live under /var/log, organized into subdirectories per service, such as /var/log/nginx or /var/log/mysql. Most distributions run logrotate automatically to compress and eventually delete old logs so they do not grow forever.

Why does /var sometimes get its own disk partition?

Because /var can grow unpredictably, especially on a server generating heavy logs or a mail server accumulating a large spool, putting it on a separate partition protects the rest of the system from a single runaway log file filling all available disk space. If /var and / share a partition and /var fills it completely, services can fail to write logs, temporary files cannot be created, and in severe cases the system can become unresponsive or fail to boot cleanly.

What is the difference between /var/log and /var/lib?

/var/log holds human-readable text log files documenting what has happened over time, meant to be read by administrators or monitoring tools. /var/lib holds the actual working data and state for installed packages and services, such as database files, package manager metadata, and application data directories. A database server, for example, writes its query logs to /var/log/postgresql but stores the actual table data in /var/lib/postgresql.

How do I find what is filling up /var?

Run du -sh /var/* 2>/dev/null | sort -h to get a sorted breakdown of every subdirectory under /var by size. On most systems, /var/log and /var/cache are the usual suspects for unexpected growth. Within /var/log specifically, du -sh /var/log/* | sort -h narrows it down further to the exact service or application responsible.

What is logrotate and how does it manage /var/log?

logrotate is a utility that runs on a schedule (usually daily, via cron or a systemd timer) and automatically compresses, archives, and eventually deletes old log files according to rules defined in /etc/logrotate.conf and /etc/logrotate.d/. Without it, log files would grow indefinitely. A typical rule rotates a log weekly, keeps four weeks of compressed history, and deletes anything older, keeping /var/log from consuming unbounded disk space over time.