A VPS disk full error can interrupt database writes, uploads, logs and package operations at the same time. The immediate temptation is to delete the largest visible files, but that can destroy useful data without addressing the cause. Diagnosis should first identify which filesystem is constrained and what kind of capacity has run out.
Linux can run short of data blocks, inodes or a quota even when another dashboard appears to show free space. Tools also measure different things, so their totals may not match directly. The workflow below emphasizes read-only inspection before any cleanup and avoids treating application data as disposable.
This article on getaboutcolumbia explains how to locate growth, choose a safe recovery action and verify the application afterward. It also shows how to turn an emergency cleanup into a durable storage policy.
Identify the affected filesystem and capacity type
Begin with the error message, the time it appeared and the path involved. An upload failure under a separate media mount is not necessarily a full root filesystem. A database may also use a different volume from the web application. Map the failing path to its mount before deciding what needs attention.
The df manual documents filesystem capacity reporting and the inode reporting option. df -h gives a readable view of block usage, while df -i helps identify inode exhaustion on filesystems where this applies. Millions of tiny files can consume inodes even when substantial data capacity remains.
Check account or application quotas where relevant. A hosting panel may impose a limit below the size of the underlying filesystem, and containers may have storage arrangements that make host-level figures confusing. Record the exact failing layer instead of assuming that buying a larger root disk will resolve every storage error.
If the server still accepts administration, preserve that access and avoid starting large diagnostic exports on the constrained filesystem. The broader first-hour incident workflow helps prioritize service recovery while retaining evidence. A fresh backup that writes to the same full disk can worsen the immediate problem.
Locate growth without deleting blindly
The du documentation describes estimating file and directory space usage. Inspect likely top-level application and log directories with appropriate permissions and filesystem boundaries. A command restricted to one filesystem helps avoid counting a mounted backup volume as if it were part of the root disk.
Compare results carefully. df describes filesystem allocation, while du totals files it can traverse. Permission restrictions, separate mounts, filesystem metadata and files deleted while still held open can contribute to differences. A large discrepancy is a reason to investigate, not proof that either tool is broken.
Look for recent changes: a backup job retaining too many archives, an error log growing continuously, failed uploads accumulating temporary files or a new cache producing many small objects. Directory names alone do not establish whether content is safe to remove. Determine which service owns the files and what recovery or retention policy applies.
For an illustrative case, suppose a 60 GB filesystem has filled after a daily backup began keeping ten local archives of about 4 GB each. Deleting one verified redundant archive may create breathing room, but the sustainable fix is to change retention and transfer policy. Without that second step, tomorrow's job recreates the incident.
System journals have their own tooling. The journalctl manual describes disk usage inspection and vacuum operations for archived journal files. Before applying retention changes, preserve logs needed for the current incident or applicable obligations. Do not assume ordinary text-file rotation governs every logging system.
Recover space through the owning service
Choose the smallest safe action that provides enough room for diagnosis and normal writes. Candidates may include verified redundant backup copies, expired application cache through the application's own controls or retained package downloads through supported package tooling. Each action requires confirmation of ownership and recoverability.
Avoid deleting database files, active transaction logs or unfamiliar files under system directories. Those files may be essential even if their size is inconvenient. Database cleanup should use database-supported procedures with an appropriate backup and a clear understanding of whether the operation itself needs temporary free space.
If a deleted file remains open, releasing its space can require the owning process to close it. Do not restart a critical database merely to experiment. Identify the process, assess the impact and use its supported log reopening or maintenance procedure. A controlled service action is preferable to terminating processes indiscriminately.
Consider expansion when cleanup cannot safely create sufficient capacity. Verify provider limits, filesystem growth requirements and whether a snapshot or backup is available before modifying storage. Increasing the disk may require a separate partition or filesystem step, and a larger volume does not correct unlimited file growth.
After space becomes available, test database writes, uploads and any jobs that failed. Check for partial outputs or retries that could create duplicates. Service recovery means that useful work succeeds again, not only that the free-space percentage changed.
Mistakes to avoid
Do not run recursive deletion commands against guessed paths, remove current backups without verifying another usable copy or erase incident logs before understanding the event. Avoid forcing package cleanup while another package operation is active. A proper log-rotation policy and a complete hosting backup policy address two common growth sources before they become emergencies.
Two final recommendations
Set storage alerts with enough time to act and include the growth rate. A filesystem gaining several gigabytes per hour needs different urgency from one slowly approaching a threshold over several months.
Record the recovered space, the owning service and the underlying change that caused growth. Assign a follow-up action to retention, capacity or application behavior so the incident is not closed after a temporary deletion alone.
Conclusion
When a VPS disk is full, identify the filesystem and capacity type before deleting anything. Safe recovery follows evidence about file ownership, growth and the application's ability to restore data.
Use filesystem and directory measurements together, reclaim only verified disposable content and test the services that failed. Expand storage deliberately if the workload genuinely needs more capacity.
Finish by correcting the growth mechanism and improving alerts. The most useful outcome is not a briefly empty disk but a storage system whose behavior you can predict.
