A full disk is one of the most common server issues and can cause serious problems: services crash, databases stop accepting writes, applications throw errors, and you may even lose the ability to log in. The good news is that diagnosing and fixing disk space issues is straightforward once you know where to look.

This guide walks you through checking disk usage, finding the largest files and directories, safely cleaning up space, and preventing the problem from recurring.

Recognizing the Problem

A full disk can manifest in various ways:

• Error messages like "No space left on device" or "Disk quota exceeded"
• Services failing to start — web servers, databases, and other services may refuse to start if they cannot write to disk
• Databases refusing writes — MySQL, PostgreSQL, and other databases stop accepting new data
• Log files not rotating — applications cannot write logs, causing silent failures
• Unable to log in — in extreme cases, the server cannot create the temporary files needed for SSH sessions
• Website showing errors — 500 Internal Server Error pages

Step 1 — Check Disk Usage

Connect to your server via SSH or the web console and check the overall disk usage:

df -h

This shows disk usage for all mounted filesystems in human-readable format. Key columns:

Check Inode Usage

In rare cases, the disk has free space but has run out of inodes (file system entries). This happens when there are millions of tiny files:

df -i

If IUse% is at 100%, you need to delete files (not just free space) to resolve the issue.

Step 2 — Find What Is Using the Space

Check Top-Level Directory Usage

Start by seeing which directories under root are consuming the most space:

du -sh /* 2>/dev/null | sort -rh | head -15

This shows the total size of each top-level directory, sorted from largest to smallest. Common results:

• /var — Often the largest. Contains logs, databases, package caches, and application data.
• /home — User home directories and website files.
• /usr — System binaries and installed packages.
• /opt — Optional application installations.
• /tmp — Temporary files.

Drill Down Into the Largest Directory

Once you identify the largest top-level directory, drill down further:

# If /var is the largest
du -sh /var/* 2>/dev/null | sort -rh | head -10
Then drill down further
du -sh /var/log/* 2>/dev/null | sort -rh | head -10

Repeat this process until you find the specific files or directories consuming the most space.

Find the Largest Individual Files

Search for the biggest individual files on the entire disk:

find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -k5 -rh | head -20

This finds all files larger than 100 MB and lists them sorted by size. Common large files include:

• Old log files
• Database dump files
• Downloaded archives
• Core dump files
• Old backup files

Step 3 — Clean Up Disk Space

Work through these cleanup actions in order, starting with the safest and most impactful options.

3.1 — Clean Up Log Files

Log files are one of the most common causes of full disks, especially on servers that have been running for months without log rotation.

# Check log directory size
du -sh /var/log/
Find the largest log files
ls -lhS /var/log/ | head -20

Truncate large log files (instead of deleting them, which can cause issues with running services):

# Truncate a specific log file to zero bytes
truncate -s 0 /var/log/syslog
truncate -s 0 /var/log/kern.log
Truncate old rotated logs
truncate -s 0 /var/log/syslog.1

Remove old compressed log archives:

# Remove all gzipped log archives
rm -f /var/log/*.gz
rm -f /var/log/*.1
rm -f /var/log/*/.gz

Set up proper log rotation to prevent this in the future. Check that logrotate is configured:

cat /etc/logrotate.conf
ls /etc/logrotate.d/

A good logrotate configuration keeps only the last 7-14 days of logs and compresses older files:

/var/log/syslog {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
}

Force an immediate log rotation:

logrotate -f /etc/logrotate.conf

3.2 — Clear Package Manager Cache

Package managers download and cache packages during updates. These caches can grow large over time.

# Ubuntu / Debian — clear apt cache
apt clean
apt autoclean
Check how much space the cache uses
du -sh /var/cache/apt/
AlmaLinux / Rocky / CentOS — clear dnf cache
dnf clean all

3.3 — Remove Old Packages and Kernels

Remove packages that were installed as dependencies but are no longer needed:

# Ubuntu / Debian
apt autoremove -y
AlmaLinux / Rocky / CentOS
dnf autoremove -y

On Ubuntu/Debian, old Linux kernels can accumulate and consume significant space. Remove old kernels (keep the current one and one previous version):

# List installed kernels
dpkg --list | grep linux-image
Remove a specific old kernel
apt remove --purge linux-image-[old-version] -y

3.4 — Clean Up Temporary Files

# Check temp directory sizes
du -sh /tmp/
du -sh /var/tmp/
Remove old temporary files (files not accessed in 7+ days)
find /tmp -type f -atime +7 -delete 2>/dev/null
find /var/tmp -type f -atime +7 -delete 2>/dev/null

3.5 — Find and Remove Old Backups and Dumps

Database dumps, manual backups, and downloaded archives are common space hogs:

# Find .sql dump files
find / -name "*.sql" -size +50M -ls 2>/dev/null
Find .tar.gz archives
find / -name "*.tar.gz" -size +50M -ls 2>/dev/null
Find .zip files
find / -name "*.zip" -size +50M -ls 2>/dev/null

Delete any dumps or backups that are no longer needed. If you need to keep them, consider moving them to a dedicated Storage VPS or downloading them to your local machine before deleting.

3.6 — Clean Up Docker (If Applicable)

Docker can consume enormous amounts of disk space with unused images, containers, and volumes:

# Check Docker disk usage
docker system df
Remove all stopped containers, unused images, and build cache
docker system prune -a -f
Remove unused volumes (WARNING: this deletes data in unused volumes)
docker volume prune -f

3.7 — Clean Up Journal Logs

On systems using systemd, journal logs can grow very large:

# Check journal size
journalctl --disk-usage
Keep only the last 3 days of journal logs
journalctl --vacuum-time=3d
Or limit journal size to 200MB
journalctl --vacuum-size=200M

To set a permanent size limit, edit /etc/systemd/journald.conf:

SystemMaxUse=200M

Restart the journal service:

systemctl restart systemd-journald

Step 4 — Verify the Cleanup

After cleaning up, verify the results:

df -h

You should see the Use% for your root partition has decreased. Aim to keep disk usage below 80% for normal operations — this gives you buffer for log growth, temporary files, and updates.

Restart Affected Services

If services stopped working due to the full disk, restart them:

# Restart web server
systemctl restart nginx    # or apache2
Restart database
systemctl restart mysql    # or postgresql
Restart your application
systemctl restart your-application

Preventing Future Disk Full Issues

Set Up Monitoring

Configure disk usage alerts in your Data Mammoth dashboard or use a monitoring tool. Set thresholds at:

• Warning at 70% — Start planning cleanup or expansion
• Critical at 85% — Take action immediately
• Emergency at 95% — Disk full is imminent

Automate Log Rotation

Ensure logrotate runs daily and is properly configured for all services. Check the logrotate timer:

systemctl status logrotate.timer

Schedule Regular Cleanup

Create a weekly cron job for routine cleanup:

crontab -e

Add:

0 3   0 apt clean && journalctl --vacuum-time=7d

This runs every Sunday at 3 AM, cleaning the package cache and trimming journal logs.

Consider Expanding Storage

If you consistently need more space than your current plan provides:

• Upgrade to a plan with more storage. See How to Choose the Right VPS Plan.
• Add a dedicated Storage VPS for backups and archives.
• Offload static assets to a CDN or object storage service.

Related Articles

• Server Not Responding — Troubleshooting Guide
• High CPU Usage — Diagnosis & Fix
• Cannot Connect via SSH — Troubleshooting
• How to Choose the Right VPS Plan

Need Help?

If your disk is completely full and you cannot log in via SSH, use the web console in your Data Mammoth dashboard to access your server and perform the cleanup steps above. If you are unable to resolve the issue or need help identifying what is consuming space, open a support ticket with the output of df -h and du -sh /* | sort -rh. Our team will help you diagnose and resolve the issue quickly.