Safe Diagnosis and Resolution When Linux VDS Disk Space Is Full

When disk space runs out on a Linux VDS, determine which file system and directory is growing before deleting files. If you have SSH and administrator access, compare disk usage, inode status, and application records from the same minute. If logs are the source of the problem, correct only the relevant logging policy; if the database or uploaded files have grown, use a different capacity plan.

First check on a Linux VDS: capacity or inodes?

This procedure is suitable for a Linux VDS that can be accessed with administrator privileges. You cannot inspect the root file system through a shared hosting panel; in that case, you are limited to the panel’s disk-usage screen and the error records provided by the hosting provider. An SSH connection, a separate administrator account if possible, and a backup of the current configuration—or at least a written record of the value you will change—should be ready.

First, record the failed operation: for example, the time when the application could not upload a file, the resulting HTTP status, or the database error. Then use the read-only df -h command to inspect the usage percentage of the file systems. If usage is close to 100 percent, a capacity problem is likely. If usage appears reasonable but new files cannot be created, the inode count may be exhausted; on some systems, this value appears in the output of df -i.

If the result shows that capacity is full, first identify the top-level directories inside the growing file system; if inodes are exhausted, investigate cache, session, or temporary-file areas that create many small files. Do not confuse these two findings: a large backup can fill capacity, while millions of small session files can hit the inode limit.

Separate the source based on evidence

The source consuming disk space is usually application logs, user uploads, database files, backups, or temporary storage. The journalctl --disk-usage command is meaningful only on distributions that use systemd logging; if it is not recognized, do not treat that alone as evidence of a general failure. Evaluate the application’s own upload and backup screens together with the file-system output.

For example, on a hypothetical Linux VDS, a file-upload request returns an error similar to “disk quota exceeded,” while df -h shows 99 percent usage on the root file system. If an inspection of the top-level directories shows that the growth is in the application’s upload directory, changing log rotation is not the correct solution. First classify the application’s retention policy and no-longer-used uploads using the application’s own safe tool; then consider increasing capacity or using separate storage. If the same symptom appears in the log directory, the targeted solution is log rotation and the retention period.

Order to follow for a safe correction

1. Record the current state. Save the output of df -h and, if necessary, df -i, along with the time of the failed request and the relevant application log line. This prevents you from confusing the later result with the previous state.
2. Verify the growing area. With administrator privileges, use a disk-usage tool appropriate for your distribution or the directory report in the hosting panel. If logs occupy the most space, inspect the logging manager’s rotation and retention settings; if uploads are responsible, check the application’s archiving policy before deleting files.
3. Make one targeted change. If log rotation is configured but not working, correct the schedule, ownership, and retention values in the configuration; do not delete all system logs without limits. Record the old value and do not change multiple limits at the same time. If the upload area has grown, use safe archiving or the disk-expansion option offered by the provider.
4. Retry the operation. Repeat the same URL request, file upload, or application operation. In the new time-stamped log line after the change, check that the previous “no space” finding has disappeared, that the new file was written to the expected directory, or that the application did not produce another error.
5. Interpret the result. If disk usage has fallen but the operation still fails, there may also be a permissions issue, an application quota, or a database limit; treat the new error line as a separate symptom. If usage rises rapidly again, stop the source of the growth instead of relying on temporary cleanup, and review the capacity plan.

Safe rollback if the change does not work

If new records show the same problem and the setting you changed causes unexpected behavior, first restore the value you recorded. If you changed log rotation, restore the previous retention and scheduling values; however, do not restart the service before verification. On some distributions, applying the configuration may require reloading the relevant logging service; the correct command and sequence depend on the operating-system version and the administrator in use.

If the file system is still full, do not delete files or database data without evidence. Use the application provider’s supported archiving method, an additional disk option, or disk-expansion procedure. When evaluating the infrastructure option you need, you can review the Turkey VDS server plans page; to determine suitable capacity, also account for the current usage, monthly growth rate, and the space occupied by backups.

Next safe step

Now first obtain the df -h output and, if necessary, the df -i output, find the record from the same time period as the failed operation, and make only one change aimed at the source confirmed by the evidence. If the problem recurs, comparing the new time-stamped output with the previous record is a safer next step than random cleanup.