Server Disk Space Calculator
Figure out how much storage you actually need before you run out.
Log retention by compliance requirement
| Standard | Minimum retention | Notes |
|---|---|---|
| PCI DSS | 12 months | 3 months immediately available, rest in archives |
| HIPAA | 6 years | Audit logs for systems handling PHI |
| SOC 2 | 12 months | Varies by auditor, 12 months is typical |
| GDPR | No fixed period | "No longer than necessary" - keep it short, document your reasoning |
| ISO 27001 | Org-defined | You pick the retention, but you have to follow it consistently |
If you don't have compliance requirements, 30-90 days is a practical default for most teams.
Strategies for reducing log volume
Run DEBUG in development, INFO or WARN in production. A single application flipping to DEBUG can easily 10x your log volume overnight.
For high-traffic endpoints, log 1 in 100 successful requests but keep every error. You lose nothing useful and cut volume dramatically.
Text logs compress well. Gzip typically achieves 5-10x compression on log files. Most log shippers and rotation tools handle this automatically.
JSON logs look bigger per line but they're easier to filter and parse. Drop fields you never query. A well-structured log line beats a verbose unstructured one.
Log rotation vs log shipping
Log rotation (logrotate, journald)
Keeps logs on the server, rotates and compresses old files, deletes after a set period. Simple, no external dependencies. Fine when you only need logs for debugging recent issues on individual servers. Breaks down when you need to search across multiple machines or keep logs after the server is gone.
Log shipping (rsyslog, Fluentd, Vector)
Sends logs off-server to a central location (Elasticsearch, S3, a log management service). More moving parts, but logs survive server failures, you can search across your whole fleet, and you can set different retention policies per destination. Worth the setup if you have more than a few servers.
Both
The practical answer for most teams: rotate locally with short retention (7 days) as a buffer, ship everything to a central store for longer retention. Local logs for quick debugging, central store for investigations and compliance.
Warning signs your disk is filling up
Services writing to /var/log stop working silently. Applications that can't write logs often fail in unpredictable ways. Database write-ahead logs need disk space too.
Inode exhaustion. Millions of small log files can exhaust inodes before you run out of bytes. Check df -i not just df -h.
Deleted files still consuming space. If a process has a file open and you delete it, the space isn't freed until the process closes the file handle. Common with long-running services and rm without restart.
Sudden log spikes from error loops. An application throwing exceptions in a tight loop can fill a disk in hours. One bad deployment, one unreachable dependency.
Don't wait until 100%. fivenines.io alerts you before disk space becomes critical - set custom thresholds per server and get notified at 80%, 90%, or wherever makes sense for your setup.
How to Check Disk Space on Linux
Three commands cover most disk space investigations:
df -h
Shows disk usage per filesystem. The Use% column is what you want. Look for any partition above 80%.
du -sh /var/log/* | sort -rh | head -10
Find the 10 largest items in /var/log. Change the path to investigate any directory. The -s flag summarizes each entry instead of listing every file.
ncdu /
Interactive disk usage viewer. Navigate directories with arrow keys, press d to delete. Install with apt install ncdu or yum install ncdu. The best tool for exploring what's eating space.
Also check inode usage with df -i. Each file and directory consumes one inode. If you have millions of tiny files (common with some caching systems), you can run out of inodes while still having gigabytes of free space. The symptoms are identical to a full disk: writes fail and services break.
Disk Space Monitoring Best Practices
Disk space problems are the most preventable kind of outage. Unlike CPU spikes or memory leaks that can appear suddenly, disks fill up gradually and predictably. The trick is setting alerts early enough to act before things go sideways.
Set tiered alert thresholds. A warning at 80% gives you time to plan: clean up old logs, expand the volume, or archive data. A critical alert at 90% means "handle this today." An emergency at 95% means "drop everything." The right thresholds depend on your growth rate. If your disk usage grows 1% per day, 80% gives you 20 days. If it grows 5% per day, you need earlier warnings.
Monitor growth rate, not just current usage. A disk at 60% that grew 10% in the last week is more urgent than one at 85% that's been stable for months. Tracking the rate of change lets you predict when you'll hit the wall, and that's far more useful than a static threshold. fivenines.io alerts can catch these trends automatically.
Don't forget /tmp and /boot. Most monitoring focuses on the main data partition, but a full /tmp breaks application uploads and builds. A full /boot prevents kernel updates and can leave your system unable to reboot after a crash. Monitor every mounted filesystem, not just /.
Related Resources
- Server Alerting & Notifications -Set disk space thresholds and get alerted before you run out
- Load Average Interpreter -Check if I/O from full disks is affecting system performance
- SLA Uptime Calculator -Understand how disk-related outages impact your SLA
- Docker Monitoring -Track Docker image and volume disk usage across your fleet
Monitor disk space before it becomes an outage
Start monitoring with fivenines.io