Ubuntu Emergency Disk Space Recovery: A Complete Survival Guide

Picture this: It’s late, and your phone buzzes with an urgent alert disk space on your Ubuntu server has hit 100%. Your website is down, database writes are failing, new SSH sessions can’t be created, and the error logs are filling with “No space left on device.” If you’re lucky, you still have a shell open. If not, you might be staring at an unresponsive login prompt or a system stuck in maintenance mode.

This scenario is a rite of passage for anyone managing Linux servers. Whether you’re running a small blog, a critical business application, or a home file server, running out of disk space is a stressful but entirely survivable event if you know what to do, and you do it calmly.

This guide is your roadmap. Here you’ll find practical, battle-tested steps for regaining control of a disk-full Ubuntu system, techniques for finding and freeing space quickly, and advice for ensuring you never get caught off guard again.

Step 1: Stay Calm and Get Access

First, take a deep breath. While a full disk can cause all sorts of mayhem, the odds are very good that you can repair things without data loss. Your top priority is to regain access to the system.

• If you have an open SSH session: Hold on to it! Don’t log out until you’ve made room SSH logins may fail if the disk is full.
• If you’re locked out via SSH:
  • Try using the host’s console (cloud providers and hypervisors often offer a web console).
  • If you have physical access, use the keyboard and monitor directly.
  • Reboot into recovery mode or single-user mode via the GRUB boot menu (hold Shift or Esc during boot, select “Advanced options” → “recovery mode”).

Step 2: Identify Which Partition Is Full

Once you have a shell, your first move is to identify where the problem is. You need to know which partition or mount point is out of space, not just that the root disk is full.

df -h

This command displays each mounted filesystem’s size, used space, and free space in a human-readable format. Look for partitions at or near 100% usage especially /, /var, /tmp, /home, or any custom mount points. Note which are critical system locations (running out of space on / or /var can break the entire system).

Step 3: Hunt Down the Biggest Space Hogs

Once you know where the squeeze is, your mission is to quickly free up space in that partition. You need to identify which files or directories are the biggest offenders.

a) Use du to Find Large Directories

Start at the root of the full partition and look for the largest subdirectories:

sudo du -xh --max-depth=1 / | sort -rh | head -20

Replace / with the full path of the affected mount point if needed (e.g., /var). This will give you a ranked list of the largest directories. Drill down into the largest ones, repeating the du command inside each, until you find the likely culprit.

b) Use find to List Giant Files

To find the largest individual files (over 100MB), use:

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

This helps you spot forgotten backups, log files gone wild, or stray database dumps.

Step 4: Quickest Wins Free Up Space Fast

Now, it’s time to create some breathing room. These actions can quickly free up enough space for the system to function and let you dig deeper.

a) Clean the Package Manager Cache

Ubuntu stores downloaded .deb packages in /var/cache/apt/archives, which can get huge over time.

sudo apt clean

This alone can reclaim hundreds of megabytes or more, especially if you’ve done many upgrades.

b) Empty /tmp and /var/tmp

Temporary files often accumulate and are safe to remove for most servers (unless you know a specific application is using them).

sudo rm -rf /tmp/* 
sudo rm -rf /var/tmp/*

Be careful with the rm -rf command ensure you’re targeting the right directory!

c) Truncate Overgrown Log Files

Log files, especially in /var/log, can balloon out of control due to application errors, improper log rotation, or verbose services.

Don’t delete log files that are in use truncate them instead to avoid breaking services:

sudo truncate -s 0 /var/log/*.log 
sudo truncate -s 0 /var/log/**/*.log

If some logs are archived (like .gz or .1 files), remove old archives:

sudo rm -f /var/log/*.gz /var/log/*.1 /var/log/**/*.gz /var/log/**/*.1

d) Remove Old Kernels (Carefully)

Running sudo apt autoremove --purge will clear out old, unused kernels and dependencies. Do not remove the current or previous kernel unless you know what you’re doing.

Step 5: More Aggressive Cleanup & Advanced Tactics

Still tight on space? Try these strategies.

a) Move or Compress Big Files

If you have a secondary disk or partition with space, move noncritical or bulky files out of the full partition:

mv /var/backups/hugefile.tar.gz /mnt/bigdisk/

Or, temporarily compress large logs or data files:

gzip /var/log/somehuge.log

b) Offload to Another Machine

If you have network connectivity, copy large files to a remote system:

scp /var/log/bigfile.log user@remote:/tmp/
rm /var/log/bigfile.log

Or use rsync.

c) Find and Handle Orphaned Deleted Files

Sometimes, space doesn’t reappear after deleting files because a running process is still holding them open. To track these down:

sudo lsof | grep deleted

This will show processes with open handles to deleted files. Restart the relevant service or kill the process to truly free the space.

Step 6: Emergency Measures Boot Issues and Read-Only Filesystems

If your system won’t boot due to a full root partition, or if the filesystem is mounted read-only after a crash:

1. Boot into recovery mode: At the GRUB menu, select Advanced, then (recovery mode).
2. Remount root as read-write:

   mount -o remount,rw /

3. Use the same cleanup techniques as above to free space.
4. If all else fails, you can mount the disk from a rescue/live USB or VM, chroot in, and clean up from there.

Step 7: After Recovery Verify and Reboot

Once you’ve freed up enough space (at least 200–500MB), check with:

df -h

Start or restart critical services (web, database, SSH) and verify basic functionality. If needed and safe, reboot your server for a clean start:

sudo reboot

Step 8: Root Causes and Long-Term Prevention

A full disk is a symptom, not a disease. Once the immediate crisis is over, take time to understand what filled your disk and implement safeguards.

1. Set Up Monitoring: Use tools like Prometheus, Nagios, or simple cron scripts that check disk usage and send alerts when usage exceeds, for example, 80%. Example script to email when / is nearly full:

   #!/bin/bash
       PERCENT=$(df / | grep / | awk '{ print $5 }' | sed 's/%//g')
       if [ $PERCENT -gt 80 ]; then
           echo "Disk usage is above 80%" | mail -s "Disk space warning" [email protected]
       fi

2. Automate Log Rotation: Ensure /etc/logrotate.conf and /etc/logrotate.d/ are properly configured so logs don’t grow unchecked. Manually trigger logrotate if needed:

   sudo logrotate -f /etc/logrotate.conf

3. Clean Up Regularly: Schedule regular cleanups of package caches and orphaned packages:

   sudo apt autoremove
       sudo apt autoclean

4. Educate Users and Developers: If users or applications are writing massive files, work with them to implement quotas, better data management, or regular archival.
5. Review Partitioning: Consider separating /var, /tmp, /home, and / onto different partitions. This prevents logs or user data from filling root and crashing the entire system.
6. Backups and Recovery Planning: Keep regular backups so that, if all else fails, you can restore lost data or rebuild cleanly.

Real-World Stories and Pitfalls

The Log File Explosion:

A misconfigured application once dumped debug logs at a rate of 10GB/hour, filling /var and crashing MySQL. Logrotate was set to weekly, making the problem worsen. After truncating the logs and adjusting logrotate to daily with size-based rotation, the issue never returned.

Orphaned Files:

Deleted multi-gigabyte log files didn’t free space because Apache was still writing to them. Restarting Apache immediately reclaimed several gigabytes.

Forgotten Backups:

Nightly scripts dumped database backups to /home but never deleted old ones. The fix was to add a find ... -mtime +7 -delete step to keep only the last week’s backups.

Conclusion: Be Proactive, Not Reactive

Recovering from a full-disk situation on Ubuntu is stressful, but absolutely manageable. The key is to stay calm, systematically identify and remove the largest, least essential files, and restore enough space for the OS to function. Once you’re out of the woods, invest a little time to set up monitoring, automate cleanup, and review your storage policies. These simple steps will save you from future emergencies and let you sleep a lot better at night.

Remember, storage management is as much about good habits as it is about rescue procedures. Document your lessons learned, share them with your team, and always have an emergency checklist ready. That’s what separates a panicked admin from a confident one.