Why df and du Show Different Disk Usage on Linux

When a Linux VPS reports a full disk but visible directories seem smaller, the difference is usually a question of what each tool measures. Deleting random files can miss the actual cause and destroy useful evidence. Establish which filesystem is full, then compare like-for-like measurements before choosing a cleanup or capacity change.

Identify the filesystem that owns the path

Start with df -h /var or another path used by the failing application. The result describes the filesystem containing that path, which might differ from the root filesystem. The GNU df documentation explains its filesystem-level reporting. Check mounts before assuming that a directory name identifies a separate disk. Containers, bind mounts, and network mounts can make a familiar path point somewhere different from your initial expectation.

Measure visible files with a controlled scope

Use du -xhd1 /var on GNU systems to inspect first-level usage while staying on one filesystem. Administrative access may be needed to avoid silently missing restricted directories. This walk can create I/O on a busy machine, so begin with the application's known data directory when possible. Compare allocated space rather than mixing apparent file sizes with filesystem allocation. Sparse files, hard links, filesystem metadata, and reserved space can all make apparently simple totals differ.

Check for deleted files that remain open

A process can continue holding an open file after its directory entry is removed. The space is not necessarily available again until the process closes that file. This is a common explanation when a large log was deleted but df barely changed. If installed, a bounded inspection with lsof +L1 helps identify unlinked open files. Review its output privately and map the process to its service. Use the service's documented log-reopen or restart procedure when needed, considering the impact of interrupting active requests.

Work through a misleading cleanup

Suppose a log file grew to several gigabytes, an operator removed it, and the dashboard still reports nearly full storage. Repeating the deletion cannot help because the visible file is already gone. The useful questions are whether the service still holds it open, whether another filesystem owns the remaining data, and whether usage continues growing elsewhere. Record the before-and-after filesystem values, then inspect the responsible process. This turns a confusing cleanup into a specific explanation with a verifiable release of space.

Fix the growth pattern after making room

Once the immediate constraint is understood, choose an owner-approved retention action or a capacity change. Preserve recent incident evidence and required application data. Then correct the source: excessive debug logging, retained exports, forgotten uploads, or an application that never expires temporary files. Set separate alerts for current free space and sustained growth. A cleanup that buys one hour but leaves a runaway writer unchanged should be treated as temporary mitigation, with a follow-up owner and deadline.

LayerOne does not maintain VPS backups or snapshots, so verify your independent backup before removing irreplaceable data. See backup responsibilities and the help center for platform context. Storage recovery is safer when the filesystem, writer, and retention decision are all explicit.