Magento disk full: find what is eating the space

Q: Can I empty Magento's var folder?

Not all of it. The cache (var/cache, var/page_cache) can be flushed safely from the admin panel or with bin/magento cache:flush. Logs can be emptied or rotated. Error reports should be read, then archived. Sessions, on the other hand, log your customers out if you delete them.

In short

On a Magento store, the space almost always goes to the same places: logs, error reports, cache, cached images, sessions, forgotten backups, the database.
Two commands are enough to find the culprit: df -h to see which disk is full, du to see which folder is growing.
The cache can be flushed safely. Media, app/etc, pub/static and the database files are never deleted by hand.
A disk can refuse to write with gigabytes still free: it has run out of inodes. df -i tells you.

Contents

The symptoms of a full disk on Magento

A full disk gives no warning. The store runs fine, then everything breaks at once, because Magento, the database and the web server all need to write.

The most common signs:

customers who can no longer add to basket or place their order;
the storefront or the admin panel showing an error page, or nothing at all;
the database no longer responding (“MySQL server has gone away”, “Can’t connect to local MySQL server”);
backups and deployments failing;
in the logs, the message No space left on device (sometimes “Errcode: 28”).

Adobe lists these same symptoms for a database running out of space. The No space left on device message is the system’s error: it refuses to create or extend a file.

Where Magento 2 uses space: the usual suspects

Folder	What it contains	Why it grows
`var/log`	Magento’s logs (`system.log`, `exception.log`…)	Magento keeps appending and never empties these files. See log rotation.
`var/report`	One report per error shown to visitors	A recurring error creates thousands of small files.
`var/cache`, `var/page_cache`	Magento’s cache, when it is stored in files (the default setting)	It is rebuilt constantly; it can get heavy on a large catalogue.
`var/session`	Visitor sessions, when they are stored in files	On Debian and Ubuntu, PHP’s automatic session cleanup does not go into this folder.
`pub/media/catalog/product/cache`	Resized product images	One copy per image size and per photo.
Site root, home folder	Forgotten backups: `.sql`, `.sql.gz`, `.tar.gz`, `.zip`	A copy of the database or the site made “just before an update” and never removed.
The server’s `/var/log`	Web server and system logs	Traffic, attacks, errors: they grow if their own rotation is badly set up.
`/var/lib/mysql`	The database	Orders, customers, database logs, temporary tables.

When Magento shows “There has been an error processing your request” with a number (“Error log record number”), that number is the name of the report saved in var/report. A store that shows this page thousands of times fills the folder with thousands of files.

Check Magento’s disk space without a terminal

You do not need technical skills for a first look.

Look at the space used in your hosting provider’s customer area, if it shows it, or on the Tocsin24 Disk space card if the module is installed (see below).
Connect with your FTP or SFTP client (FileZilla, Cyberduck, WinSCP) or your hosting provider’s file manager, with the credentials your hosting provider or agency gave you.
Open the Magento folder, the one that contains app, pub and var, and sort by size. Look for archive files of several gigabytes.
Open var, then log and report. Log files of several hundred megabytes, or a report folder that takes a long time to display, are strong leads.

/var/www/store

Name	Size	Modified
..
app
pub
var
vendor
store-before-update.sql.gz	9.4 GB	14/03/2026
site-backup.tar.gz	21 GB	02/02/2026
composer.json	4 KB	12/09/2026

Example. Two forgotten backups at the site root: 30 GB that have no business being on the production server.

Depending on the software, a folder’s size does not appear in the list: a “Properties”, “Info” or “Calculate size” command shows it. If your client does not offer one, the message further down lets you ask your hosting provider for the analysis.

Free up space on Magento safely, and what never to touch

Safe for the store

Magento’s cache. In the admin panel, System > Tools > Cache Management, Flush Magento Cache button. Adobe describes it as the equivalent of bin/magento cache:clean. The cache rebuilds itself.
The product image cache. Same page, Flush Catalog Images Cache button: it removes the resized images from pub/media/catalog/product/cache. The original photos are not touched. The trade-off: Magento recreates each image on the first visit, which slows pages down and loads the server for a while. Do it outside peak hours.
Backups left on the server. Copy them to another medium, check the copy, then remove them from the server. The CNIL, the French data protection authority, advises against keeping backups on the same system as the data anyway.
Large logs. Empty them rather than deleting them, then set up log rotation so the problem does not come back.

Have them read before removing them

The reports in var/report. They are error traces. Have your developer read them: an error repeated thousands of times is a bug to fix, and sometimes the sign of an attack (see what to do when Magento 2 is hacked). After that, the old reports can be archived off the server.

Never delete by hand

pub/media outside the cache folder: these are your photos, your downloadable files, your page images.
app/etc, and env.php in particular: the store’s configuration and credentials.
pub/static and generated in production mode: Magento serves the deployed files and does not recreate them on its own. Deleting them means a redeployment.
var/session during the day: each file is a visitor’s session. Deleting them logs out your customers and your admins.
The files in /var/lib/mysql: the database is cleaned with its own commands, never with rm.

Not technical? The message to your hosting provider

Finding what is filling a server takes a few minutes for someone who has access to it. Here is a message ready to send:

Message to your hosting provider or agency

Hello,

The disk of our Magento store’s server is almost full (or full). Could you:

tell us which folders take up the most space, including in number of files (inodes);
remove the backups stored on the server, after keeping a copy elsewhere;
check log rotation for Magento (var/log) and for the server;
look for any error repeating in var/report or var/log/exception.log;
tell us whether the disk needs to be enlarged, and how fast it is filling up.

Please do not delete anything in pub/media (except pub/media/catalog/product/cache), app/etc or the database without talking to us first.

Thank you.

You manage the server: find what is filling the disk

The commands below only read. They are written for Debian or Ubuntu, with a store in /var/www/store: replace the path with yours.

Which disk is full, and of what? df -h gives the space on each disk. df -i gives the number of inodes, that is, of possible files.

Terminal

df -h df -i

Find the line at or near 100%, and note its mount point (/, /var, /home…).
Which folder takes up the space? Start from the root of the full disk, without crossing onto other disks (the -x option), and sort by size.

Terminal

The largest folders on the root disk, from smallest to largest sudo du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -n 15

Then go down into the largest folder, replacing / with its path. If ncdu is installed, sudo ncdu -x / does the same thing interactively.
Within Magento, which folders?

Terminal, from the Magento folder

Size of the folders in var and pub/media du -sh var/* pub/media/* 2>/dev/null | sort -h Size of the product image cache du -sh pub/media/catalog/product/cache
Large individual files, forgotten backups in particular:

Terminal

Files over 500 MB on the root disk sudo find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null Archives and database dumps over 100 MB under /var/www and /home sudo find /var/www /home -xdev -type f \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.tar.gz' -o -name '*.zip' \) -size +100M -exec ls -lh {} +
Deleted files that are still open. If df says the disk is full while du does not find that many files, a program is holding open a file that has already been deleted, often a large log.

Terminal

sudo lsof +L1

The SIZE/OFF column gives the space held, the COMMAND column the program. The space comes back when that program restarts (PHP-FPM, web server, message queue consumer). lsof is not always installed: sudo apt install lsof.
System logs and the database.

Terminal

Space used by the system journal (journald) journalctl --disk-usage Web server and system logs sudo du -sh /var/log/* 2>/dev/null | sort -h Size of the database on disk sudo du -sh /var/lib/mysql

To see the heaviest tables, run this read-only query in the Magento database:

MySQL or MariaDB client

SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024) AS size_mb FROM information_schema.tables WHERE table_schema = DATABASE() ORDER BY (data_length + index_length) DESC LIMIT 10;

Free up space on the server

Magento’s cache, from the store’s folder: bin/magento cache:flush. Adobe points out that flush empties the whole cache storage: if it is shared with another application (a shared Redis, for example), use bin/magento cache:clean instead.
The system journal: sudo journalctl --vacuum-size=500M removes the oldest archives until it is back under 500 MB.
The database’s binary logs (if replication or continuous backup uses them): they are removed with PURGE BINARY LOGS, which also keeps the list of logs up to date. Never with rm, and never before checking that no replica is still reading them.

Terminal, from the Magento folder

Flush Magento's cache bin/magento cache:flush Shrink the system journal to 500 MB sudo journalctl --vacuum-size=500M

For developers

File-based sessions on Debian and Ubuntu. Adobe notes that session.gc_probability is 0 by default on these systems: PHP never cleans up expired sessions itself. Debian hands this job to a scheduled task (/etc/cron.d/php, script /usr/lib/php/sessionclean), but it only covers PHP’s session.save_path folder, not Magento’s var/session. The result: one file per visit, never deleted, until the inodes run out. Adobe documents two solutions: set gc_probability, gc_divisor and gc_maxlifetime in the session section of app/etc/env.php, or store sessions in Redis.

Disk full with space still left: inodes

Every file takes up an “index card” on the disk, called an inode, on top of its content. The number of cards is set when the disk is formatted: on ext4, the most common file system on Debian, it cannot be changed afterwards. A folder holding millions of tiny files can therefore use up all the cards long before the space.

The symptom is misleading: df -h shows free space, but every attempt to create a file fails with the same No space left on device.

Tried on a test disk limited to 200 files:

Result on a test disk

touch: cannot touch 'f199': No space left on device Filesystem Size Used Avail Use% Mounted on tmpfs 50M 0 50M 0% /mnt/petit Filesystem Inodes IUsed IFree IUse% Mounted on tmpfs 200 200 0 100% /mnt/petit

The disk is 0% used, but 100% of its inodes are taken. To find the folder that holds the most files:

Terminal, from the Magento folder

du --inodes -x --max-depth=1 var | sort -n

On Magento, the suspects are almost always var/session (sessions never cleaned up), var/report (a recurring error) and pub/media/catalog/product/cache.

Stop Magento’s disk from filling up again

Set up log rotation for Magento: it is the most common cause. Our step-by-step guide.
Move backups off the server and check that they can be restored. A backup on the same disk as the store protects against nothing. See the backups point in our audit.
Have recurring errors fixed in var/report and exception.log.
Set up session cleanup if sessions are stored in files.
Watch the trend, not just the level: a disk at 70% that gains 5% a week is more urgent than a stable disk at 85%.

These checks are part of the regular upkeep of a Magento store.

Tocsin24 warns you before the disk is full

With the Magento module installed, Tocsin24 records the free space on the disk that holds the store, and on those of pub/media and var if they are on another disk. The Disk space card on the dashboard turns orange below 20% free space, and red below 10% or 5 GB. It also works out how fast the disk is filling up over two weeks, and says “full in about…”.

When it turns red, Tocsin24 opens the “Disk space almost full” incident and warns you. The incident closes on its own when the space comes back. Tocsin24 also flags a system.log or exception.log file over 500 MB.

Tocsin24 deletes nothing on your server, and does not track inodes yet: a disk short of inodes still needs checking with df -i.

Try it for free See Magento 2 monitoring

Espace disque

Espace libre sur le serveur du site.

Disque du serveur racine du site À surveiller

16 Go libres sur 100 Go 84 % utilisé

+2,5 Go par semaine · plein dans environ 6 semaines Relevé le 23/10 09:00

Erreurs de l'application

Logs Magento lus par le module Tocsin24, sans accès à créer chez votre hébergeur.

Récupérés

var/log/system.log 42 Mo écrit il y a 2 min
var/log/exception.log 1,8 Go écrit il y a 3 min Rotation absente

exception.log fait 1,8 Go et remonte au 4 mars 2025 : la rotation des logs n'est pas en place.

Nous en lisons seulement les lignes récentes : la détection n'est pas gênée. Pour éviter de saturer le disque de la boutique, demandez à votre hébergeur ou à votre agence d'activer la rotation des logs Magento (archivage et compression réguliers).

Avertissement Ouvert #207

Disque du serveur presque plein : 4,2 Go libres sur 100 Go

Santé · détecté le 22 octobre 2026 à 06:10 · 1 occurrence

Traiter l'incident

Disque concerné Relevé du 22 octobre 2026 à 06:10

root: 4,2 Go libres sur 100 Go (4,2 %)
Chemin: .

Application screens with example values.

Frequently asked questions

What does “No space left on device” mean on Magento?

The system refuses to write a file: the disk has no space left, or it has run out of inodes, the “index cards” that describe each file. Check both with df -h and df -i, then look for the folder that has grown.

Can I empty Magento's var folder?

Not all of it. The cache (var/cache, var/page_cache) can be flushed safely from the admin panel or with bin/magento cache:flush. Logs can be emptied or rotated. Error reports should be read, then archived. Sessions, on the other hand, log your customers out if you delete them.

Is flushing the product image cache dangerous?

Not for your data: Magento regenerates resized images on demand. But it recreates them as visitors browse, which slows pages down and loads the server. Do it outside peak hours.

I deleted a large file and the space did not come back. Why?

A program is probably still holding it open, such as cron or the web server. The space is only released when that program stops. The sudo lsof +L1 command lists these deleted but still open files. Next time, empty the file instead of deleting it.

Should my hosting provider make the disk bigger?

Only if the growth is normal: catalogue, media, orders. If a folder swells because of an error, logs without rotation or backups left on the server, a bigger disk only puts off the outage.

Cédric Michel

Cédric has been building Magento stores for 18 years and holds the Adobe Commerce Developer Expert certification. He created Tocsin24 to monitor the security and health of Magento 2 stores and WordPress sites.

Adobe Commerce Developer Expert
Verify the certification on Adobe’s website

Magento store disk full: find out what is taking up the space