How to find what is growing on a Linux server
Find which Linux directories and files grew by comparing complete snapshots of the same verified server and scope, with scan gaps kept visible.
Direct answer
Take one complete metadata snapshot, repeat the identical scan later, and subtract matching file and directory totals. Modification time alone cannot prove growth; only comparable measurements show a size delta, and even then the path identifies correlation rather than the process that caused it.
When this guide applies
- Free space falls every day but the current largest item is not the cause.
- A log, cache, backup, upload, or container directory may be accumulating.
- You need evidence across two points in time without installing monitoring software.
Step-by-step review
Create a complete baseline
Record the verified host identity, normalized root, mount policy, scanner capability, nodes, and any coverage warnings.
Wait through a meaningful interval
Choose an interval related to the suspected job, deployment, backup, log rotation, or traffic cycle.
Repeat the exact scope
Use the same verified host, root path, filesystem-boundary rule, and compatible measurement fields.
Rank deltas
Start with directory growth, then drill into growing files and classification evidence.
Confirm the producer
Use service logs, configuration, schedules, and owners to test the hypothesis; the size delta alone does not prove causation.
Technical context
Modification time is not a growth metric
A file can be rewritten to the same size, truncated, metadata-touched, or replaced. Conversely, directory modification times do not summarize recursive byte growth.
Comparability is part of the result
Host identity, root path, mount boundary, scanner fields, and completion state must match before a delta is trustworthy.
Directory deltas explain accumulation
Aggregating child deltas up the tree helps distinguish one growing file from a directory receiving many new files.
Missing nodes need explicit states
A path absent from the second scan may have been deleted, moved, hidden by permissions, skipped, or missed by an incomplete scan.
Risks and actions to avoid
Do not baseline an incomplete scan
A later complete scan would make previously unreadable content look like new growth.
Do not compare different hosts behind one alias
Rebuilt instances, changed host keys, clusters, and load-balanced names can point to different storage.
Do not assign blame from a pathname
A process, user, deployment, restore, or replication task may write the same directory; confirm with owning-system evidence.
What the Omuuz product can—and cannot—do
What it can do
SSH Disk Visualizer can compare adjacent complete snapshots only when verified host and scan-scope identities match, then rank file and directory byte deltas.
What it cannot do
It cannot provide continuous monitoring, reconstruct changes between snapshots, or prove which process or user caused a size change.
Product evidence
