Disk full and freeing up space

Diagnose a full disk on TurboStack and safely reclaim space from logs, caches and temporary files.

A full disk breaks things quietly: writes fail, sessions cannot be saved, and deploys stop part-way. In the worst case a service crashes mid-write and corrupts data that then needs a restore. TurboStack shows you disk usage at a glance, and most space can be reclaimed safely from logs and caches without touching application data.

Symptoms

Errors containing No space left on device in application or service logs.
Writes failing - uploads, session saves, cache writes, or database writes erroring out.
Deploys or publishes failing because there is no room to unpack or build.
The site throws 5xx errors once a critical service can no longer write (see Fixing 502, 503 and 504 errors).

Diagnose it on TurboStack

On the host's Health tab, the Disk card shows current usage with an OK/Warning/Critical status and a graph. Use the 1H / 8H / 1D / 7D range buttons to see whether the disk filled gradually (growth to plan for) or suddenly (a runaway log or a one-off event). Check Top Issues for a related STABILITY issue.

To find what is using the space, connect over SSH (host SSH tab) and inspect directory sizes from your home directory downward, drilling into the largest directories first:

df -h                       # overall disk usage per filesystem
du -sh * | sort -rh | head  # largest items in the current directory
du -sh .[!.]* 2>/dev/null   # include hidden files/folders

The root disk (usually /dev/vda2, mounted on /) is the one sized in your TurboStack plan; your home directory and site files live on it, so that is the filesystem to watch.

Run du again inside the largest directory to drill down. If ncdu is available, ncdu ~ gives an interactive view: press Enter to open a directory and move down the tree until you find what is consuming space. ncdu can also delete: pressing d removes the selected file or directory permanently after a confirmation, so only use it once you are sure.

Where the space usually goes

Logs - application, web server, and service logs grow over time, and a single error loop can fill a disk fast.
var/cache and generated files - framework cache, compiled assets, and generated code (for example a Magento var/ directory) can grow large.
Sessions - accumulated session files or session data.
Media and uploads - user-uploaded images and files that simply keep growing.
Old database dumps and exports - manual .sql dumps left in the home directory.
Old restore data - files left in the ~/hprestore recovery folder after a restore.

Safe cleanup

Reclaim the easy space first, and verify what you are removing.

Truncate or remove old log files once you have noted any errors you need. Rotated/archived logs (.gz, .1, etc.) are usually safe to delete.
Clear regenerable caches - framework var/cache and compiled artifacts will be rebuilt.
Delete old database dumps and finished ~/hprestore data you no longer need.

You can also clear the in-memory caches via the TurboStack CLI over SSH:

tscli varnish clear
tscli opcache clear

Note

tscli redis clear runs redis-cli flushall on the cache instance (6379) only. It clears all cached data there but leaves the persistent instance (6378) - sessions and queues - intact, so users stay logged in. Expect a brief performance dip while the cache warms up.

tscli redis clear

Important

Do not delete application code, media you cannot regenerate, database data directories, or the persistent Redis data (port 6378). If you are unsure whether a file is safe to remove, leave it and ask your development team or Support.

If you need to recover something you removed, restore it from the host's Backups tab.

Prevent it

Keep log rotation and retention in place so logs cannot grow without bound; investigate any log that fills the disk repeatedly, since that usually points to an error loop.
Prune old database dumps, exports, and ~/hprestore data once you are done with them.
Skip redundant manual backups. TurboStack already takes daily backups of your environment to a separate server (see Backups and restore), so stacking your own daily dumps on the host mostly wastes disk. A one-off dump before a risky release is fine - remove it afterwards.
Watch the Disk card on Health and the fleet Monitoring dashboard, and act on a rising trend early.
If the disk is full of legitimate, growing data (media, database), the host needs more storage. Upgrade the plan from the Customer Center, or talk to sales.

When to contact support

Contact Support if the disk is full of data you cannot safely remove, if you need more storage, or if you are unsure what is safe to delete. Include the host, the affected domain, and what the largest directories are.