A Linux filesystem rarely jumps from healthy to full without leaving clues. Free space shrinks week by week, inode use climbs, a log rotates incorrectly, a database retains old files, or a deleted file remains open inside a long-running process. The outage arrives later, when an application can no longer write, a package update fails, or MySQL stops because its volume has no room left.
This checklist turns those clues into a short weekly Linux server monitoring routine. It is designed for developers and small-business teams managing a few servers: enough detail to find the cause, but no requirement to watch another dashboard all day.
Why a weekly disk check needs more than a percentage
A single “72% used” reading lacks context. Seventy-two percent may be comfortable on a stable 2 TB archive, but dangerous on a 40 GB root volume growing by 5 GB each week. The useful questions are how quickly usage is changing, how much working room the application needs, and whether files or inodes are responsible.
Track these four measurements for every important mount:
- space used as a percentage and in actual gigabytes;
- free space remaining;
- inode use;
- change since the previous weekly check.
Trend matters more than a universal threshold. A warning should account for both remaining capacity and time to exhaustion. If a volume has 12 GB free but is consuming 4 GB per week, it deserves attention now even though the percentage still looks acceptable.
1. Check every mounted filesystem, not only root
Begin with block usage and filesystem type. The portable command is df; adding the filesystem type helps distinguish local filesystems from temporary, container, or network mounts.
df -hT
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -f
Review /, /var, /home, database volumes, container storage, backup mounts, and application-specific paths. Confirm that expected remote or secondary volumes are actually mounted. If a data mount failed during boot, an application may silently write into the underlying root directory and fill the system disk.
Record both the percentage and available bytes. Reserve-space behavior, filesystem overhead, and different volume sizes mean that percentages alone can be misleading. Also note read-only mounts or unexpected mount-option changes, which may be symptoms of an earlier filesystem problem.
2. Check inode pressure before free space looks low
A filesystem can have gigabytes free and still reject new files when it runs out of inodes. This often happens with caches, mail queues, session directories, temporary files, or applications that create millions of tiny objects.
df -ih
sudo find /var -xdev -type f -printf '%h\n' 2>/dev/null \
| sort | uniq -c | sort -nr | head -20
The first command shows inode use by filesystem. The second is a starting point for locating directories with many files on /var; run broad searches during a suitable maintenance window because walking a large tree can create I/O load. Once you identify the likely subtree, narrow the command rather than repeatedly scanning the whole volume.
Rising inode use is a warning even when byte growth is modest. Investigate whether retention, cache eviction, session cleanup, or queue processing is broken. Do not delete an unfamiliar high-file-count directory until you understand which service owns it.
3. Find which top-level directory is growing
Use du to move from the affected filesystem toward the responsible directory. Stay on one filesystem with -x so mounted backups or remote shares do not distort the result.
sudo du -xhd1 / 2>/dev/null | sort -h
sudo du -xhd1 /var 2>/dev/null | sort -h
sudo du -xhd1 /var/lib 2>/dev/null | sort -h
Common growth locations include /var/log, /var/lib/mysql, /var/lib/docker, package caches, upload directories, CI workspaces, local backups, and forgotten application releases. Start at the mount point and descend one level at a time. This is safer and more explainable than deleting the largest files returned by an unrestricted search.
Be aware that du and df answer different questions. df reports allocated filesystem blocks; du totals visible directory entries. A large difference between them is itself a diagnostic clue.
4. Investigate deleted files that are still open
Deleting a file removes its directory entry, but Linux does not release its blocks until every process closes the file. A service can continue writing to a deleted log for days, making df report high use while du cannot find the space.
sudo lsof +L1
Look for large entries marked deleted and note the process ID, service, file descriptor, and size. The normal remedy is a controlled reload or restart of the owning service so it reopens its files. Verify application health first, use the service's documented procedure, and confirm disk space afterward. Do not kill a production process merely to reclaim space without understanding the impact.
5. Review journals, logs, and rotation health
Logs are useful until retention fails. Check journal size, the largest log paths, recent rotation results, and whether applications bypass the system rotation policy.
journalctl --disk-usage
sudo du -xhd2 /var/log 2>/dev/null | sort -h | tail -25
systemctl status logrotate.timer --no-pager
sudo logrotate --debug /etc/logrotate.conf
The debug command evaluates configuration without performing rotation, but still review its output carefully. Check for duplicate rules, wrong permissions, missing compression, an application writing to a renamed file, or retention counts that no longer fit the volume. For systemd journals, define a retention policy appropriate to incident response rather than repeatedly vacuuming files by hand.
A sudden log increase can indicate more than poor retention. It may reveal an authentication attack, crash loop, database error, network timeout, or an application switched to verbose debugging. Read a sample before cleaning anything up; the growth may be your best evidence of the underlying fault.
6. Check package, container, and deployment leftovers
Routine operations often leave recoverable space behind. Package caches, old kernels, unused container layers, build artifacts, and abandoned release directories can accumulate quietly.
# Debian/Ubuntu cache size
sudo du -sh /var/cache/apt/archives 2>/dev/null
# RPM-family cache size
sudo du -sh /var/cache/dnf 2>/dev/null
# Docker inventory; review before pruning
sudo docker system df 2>/dev/null
Inventory first and clean through the owning tool. Blindly removing files from package or container storage can corrupt metadata or delete data still needed for rollback. In container environments, distinguish images and build cache from named volumes: an apparently unused volume may hold persistent application data.
Deployment directories deserve the same discipline. Keep a documented number of known-good releases, verify the active symlink or service path, and remove only releases outside the rollback policy.
7. Check database growth and backup placement
Database storage needs application-aware review. For MySQL, growth may come from legitimate tables, binary logs, temporary files, relay logs, slow-query logs, or backups accidentally written to the data volume. A filesystem command can identify the directory, but database configuration and retention rules explain why it grew.
sudo du -xhd1 /var/lib/mysql 2>/dev/null | sort -h
mysql -e "SHOW BINARY LOGS;" 2>/dev/null
mysql -e "SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';" 2>/dev/null
Use an appropriately privileged, secret-safe login path rather than putting credentials on the command line. Never remove MySQL data files or binary logs directly with rm. Purge logs through supported database commands after confirming replication, point-in-time recovery, and backup requirements.
Also verify that backup jobs target the intended volume and that failed transfers do not leave full local copies behind. A successful backup schedule can still fill production storage if its local staging cleanup stops working.
8. Identify current high-I/O processes
Capacity tells you what has accumulated; process I/O helps show what is changing now. Use the tools available on the host and observe long enough to avoid overreacting to a short burst.
sudo pidstat -d 5 6
sudo iotop -oPa
cat /proc/pressure/io
pidstat comes from the sysstat package and iotop may require elevated privileges and kernel support. If they are unavailable, use service metrics and selected files under /proc/<pid>/io. Correlate write-heavy processes with the directories found earlier. A backup, database checkpoint, or log compression job can legitimately produce heavy I/O; the question is whether its volume and schedule match expectations.
9. Estimate time to exhaustion
Turn weekly measurements into a simple forecast. Subtract last week's used bytes from this week's figure, then divide free bytes by the average weekly growth. For example, 30 GB free at 6 GB of growth per week gives roughly five weeks of runway. Do not wait until the final week: cleanup, resizing, procurement, maintenance windows, and data migration all require lead time.
Use several observations where possible because one backup or software deployment can distort a single interval. Flag acceleration separately—a volume that grew 2 GB, then 4 GB, then 8 GB needs investigation even if its nominal runway still appears long.
10. End every check with an owner and action
A monitoring result is useful only when it produces a decision. For each warning, capture the affected host and mount, current use, weekly change, estimated runway, likely cause, immediate risk, owner, and due date. Classify actions clearly:
- Act now: critically low working space, a read-only filesystem, rapidly accelerating growth, failed writes, or database risk.
- Plan this week: short runway, broken rotation, excessive inode use, stale backups, or unexplained
df/dudifferences. - Watch the trend: expected growth with adequate runway and a documented capacity plan.
Avoid making percentage thresholds the only trigger. Keep enough headroom for package upgrades, temporary database work, log bursts, backups, filesystem behavior, and incident investigation.
Weekly Linux disk checklist
- Confirm all expected filesystems are mounted and writable.
- Record used percentage, used bytes, free bytes, and weekly change.
- Check inode use on every persistent filesystem.
- Find the top-level directories responsible for material growth.
- Compare
dfwithduand inspect deleted-open files. - Review journal size, application logs, and rotation health.
- Inventory package caches, container storage, builds, and old releases.
- Review database logs, data growth, and backup staging safely.
- Correlate active process I/O with the growing paths.
- Estimate runway, assign an owner, and set a due date.
This routine does not replace real-time alerts for an imminent full disk. It complements them by finding slow growth, retention drift, and recurring causes that urgent alerts often reveal too late. For a small fleet, a concise weekly report can provide the right level of attention without requiring someone to watch graphs continuously.
Want weekly Linux health checks without dashboard fatigue?
DMCloud Architect turns Linux and MySQL health signals into practical weekly reports, helping developers and small business owners see disk growth, inode pressure, backup age, and recurring failures before they become incidents.
Get the free starter plan for weekly infrastructure health reports.
