Why VPS disk full happens and how to resolve it: Practical Guide

What VPS disk full means and why it happens

VPS disk full means the storage partition on your virtual private server has reached 100% capacity and cannot accept new write operations. When this occurs, applications cannot create new files, databases cannot write transactions, and system processes fail with input/output errors.

Unlike shared hosting where the provider manages disk space, VPS owners are responsible for monitoring storage consumption and cleaning up files. The disk full condition affects the entire partition, stopping all services that need to write data until space is freed.

Common causes include application logs growing without rotation limits, package manager caches accumulating over time, temporary files not being cleaned automatically, database backups stored locally without purging old copies, and user-uploaded content filling application directories. Web servers, mail systems, and databases are the most common offenders because they continuously generate log files and temporary data during normal operation.

How to diagnose disk usage on your VPS

Start by checking overall disk usage across all partitions. Connect to your VPS via SSH and run df -h to display filesystem usage in human-readable format. This command shows each partition's total size, used space, available space, and usage percentage. Look for partitions at or near 100% capacity.

Once you identify the full partition, find which directories consume the most space. Navigate to the root of the full partition and run du -sh * to see the size of each top-level directory. Sort the output to identify the largest directories with du -sh * | sort -hr. This shows you where to focus your cleanup efforts.

For deeper investigation, drill down into large directories using du -h --max-depth=1 /path/to/directory. This shows space usage one level deep, helping you pinpoint specific subdirectories or files consuming storage. Common culprits are /var/log for log files, /var/cache for package caches, /tmp for temporary files, /home for user data, and application-specific directories like /var/www for web content or /var/lib/mysql for database files.

Check for hidden files that might not appear in standard listings by including the -a flag: ls -lah /directory. Hidden files, especially logs and cache files beginning with a dot, can accumulate significant space over time.

Safe methods to free up VPS disk space

Before removing any files, create a snapshot or backup of your VPS if your provider offers this feature. This gives you a recovery point if cleanup accidentally removes needed files. If snapshots aren't available, at minimum document what you plan to delete and verify you have backups of any critical data.

Start with the safest cleanup targets that rarely affect running services. Clear package manager caches first. For Debian and Ubuntu systems, run apt-get clean to remove downloaded package files, then apt-get autoremove to remove unused dependencies. For CentOS and RHEL systems, use yum clean all or dnf clean all. These commands typically free several hundred megabytes without risk.

Clean temporary files next. The /tmp directory stores temporary data that's safe to remove on most systems. Run find /tmp -type f -atime +7 -delete to remove files not accessed in the last 7 days. Adjust the number of days based on your comfort level. Some applications may store active session data in /tmp, so test this cautiously first or use a longer timeframe like 30 days.

Handle log files with care since they're valuable for troubleshooting but often consume the most space. Check /var/log for large log files using du -sh /var/log/*. Instead of deleting logs outright, truncate current logs to preserve their structure: truncate -s 0 /var/log/large-logfile.log. This empties the file while keeping it in place for applications that have it open. For archived logs with extensions like .1, .gz, or dated suffixes, these are rotated copies safe to delete: rm /var/log/nginx/access.log.*.gz.

For application-specific cleanup, identify your application directories and look for known space consumers. Web applications often accumulate cached files, session data, or temporary uploads. Check your application's documentation for safe cleanup procedures. Database systems like MySQL store binary logs that can be purged with PURGE BINARY LOGS BEFORE 'YYYY-MM-DD'; after confirming you don't need them for replication or point-in-time recovery.

Implementing log rotation to prevent future disk full issues

Log rotation automatically archives old logs and limits their total disk usage, preventing the most common cause of disk full errors. Most Linux distributions include logrotate, a system utility that handles this automatically. Check if it's running by verifying the cron job: ls -l /etc/cron.daily/logrotate.

Configure rotation for application logs that aren't managed by default. Create a configuration file in /etc/logrotate.d/ for each application. For example, to rotate Nginx logs, create /etc/logrotate.d/nginx with contents specifying the log path, rotation frequency (daily, weekly, monthly), number of old logs to keep (rotate 7), compression (compress), and handling for missing logs (missingok).

A basic logrotate configuration looks like this: specify the full path to the log file, set rotation parameters in braces, including daily rotation, keeping 7 days of logs, compressing old logs, not failing if the log is missing, and using copytruncate to truncate the original log file after copying rather than moving it. The copytruncate option is important for applications that keep log files open.

Test your logrotate configuration before relying on it. Run logrotate -d /etc/logrotate.conf to perform a dry run that shows what would happen without actually rotating files. This helps catch configuration errors. When you're satisfied, force an immediate rotation with logrotate -f /etc/logrotate.conf to verify it works as expected.

Monitor that logrotate continues working by checking the status file at /var/lib/logrotate/status. This file shows when each log was last rotated. If dates aren't updating, the cron job may not be running or configuration errors may be preventing rotation.

Setting up disk space monitoring and alerts

Proactive monitoring prevents disk full emergencies by alerting you before space runs out. Set up automated checks that notify you when disk usage crosses a threshold, typically 80% capacity. This gives you time to investigate and clean up before services start failing.

For simple monitoring without external tools, create a bash script that checks disk usage and sends email alerts. The script uses df to get usage percentage, extracts the number, compares it to your threshold, and sends mail if exceeded. Save this as /usr/local/bin/check-disk-space.sh, make it executable with chmod +x, and test it manually before automating.

Schedule the monitoring script to run automatically using cron. Add a cron job with crontab -e that runs the script hourly: 0 * * * * /usr/local/bin/check-disk-space.sh. This checks disk space at the start of each hour. Adjust the frequency based on how quickly your disk typically fills up.

For more comprehensive monitoring, consider installing a monitoring agent that integrates with your infrastructure dashboard. Tools like Netdata, Prometheus with node exporter, or cloud provider monitoring agents give you historical graphs, predictable trends, and integrated alerting. These require more setup but provide better visibility into resource usage patterns.

Set your alert threshold appropriately based on how quickly your disk fills and how quickly you can respond. An 80% threshold works for most scenarios, giving you a 20% buffer before reaching full capacity. For systems that generate logs rapidly, lower the threshold to 70% or 75% to ensure you have enough response time.

Preventive maintenance and best practices

Establish regular cleanup schedules to prevent disk space from accumulating over time. Create a monthly maintenance window to review disk usage, verify log rotation is working, clear old backups, and remove unused packages or applications. Document your cleanup procedures so they can be repeated consistently.

Implement automated cleanup scripts for predictable space consumers. Use cron to schedule jobs that remove old files from known locations. For example, purge backup files older than 30 days from your backup directory, remove uploaded files from a temporary processing directory after 7 days, or clean database exports that exceed retention policies. Always test these scripts manually first and verify they target only the intended files.

Separate data onto different partitions when possible. Keeping user data, application files, and system files on separate partitions prevents one area from consuming all space and affecting the entire system. If your VPS provider allows adding volumes or resizing partitions, consider moving high-growth directories like /var or /home to dedicated partitions or volumes.

Monitor long-term trends to predict when you'll need additional storage. Keep records of your monthly disk usage reviews to identify growth patterns. If usage increases steadily, plan to upgrade your VPS storage before you approach capacity limits. Reactive upgrades during a disk full emergency are stressful and may cause downtime.

Document your disk space management procedures in a runbook. Record where logs are stored, what your cleanup procedures are, how to trigger manual log rotation, what can be safely deleted, and who to contact if issues arise. This documentation helps during emergencies and ensures consistent handling across team members.