Disque plein sur Magento : trouver le coupable

Q: Puis-je vider le dossier var de Magento ?

Pas en entier. Le cache (var/cache, var/page_cache) se vide sans risque depuis l'administration ou avec bin/magento cache:flush. Les logs se vident ou se font tourner. Les rapports d'erreur se lisent puis s'archivent. Les sessions, elles, déconnectent vos clients si on les supprime.

En bref

Sur une boutique Magento, la place part presque toujours dans les mêmes endroits : logs, rapports d’erreur, cache, images en cache, sessions, sauvegardes oubliées, base de données.
Deux commandes suffisent pour trouver le coupable : df -h pour voir quel disque est plein, du pour voir quel dossier grossit.
Le cache se vide sans risque. Les médias, app/etc, pub/static et les fichiers de la base de données ne se suppriment jamais à la main.
Un disque peut refuser d’écrire avec des gigaoctets libres : il a épuisé ses inodes. df -i le dit.

Sommaire

Les symptômes d’un disque plein sur Magento

Un disque plein ne s’annonce pas. La boutique tourne, puis tout casse en même temps, parce que Magento, la base de données et le serveur web ont tous besoin d’écrire.

Les signes les plus courants :

des clients qui ne peuvent plus ajouter au panier ou valider leur commande ;
la boutique ou l’administration qui affiche une page d’erreur, ou plus rien du tout ;
la base de données qui ne répond plus (« MySQL server has gone away », « Can’t connect to local MySQL server ») ;
des sauvegardes et des déploiements qui échouent ;
dans les logs, le message No space left on device (parfois « Errcode: 28 »).

Adobe liste ces mêmes symptômes pour une base de données à court de place. Le message No space left on device est l’erreur du système : il refuse de créer ou d’agrandir un fichier.

Où Magento 2 prend de la place : les suspects habituels

Dossier	Ce qu’il contient	Pourquoi il grossit
`var/log`	Journaux de Magento (`system.log`, `exception.log`…)	Magento écrit à la suite et ne vide jamais ces fichiers. Voir la rotation des logs.
`var/report`	Un rapport par erreur affichée aux visiteurs	Une erreur qui se répète crée des milliers de petits fichiers.
`var/cache`, `var/page_cache`	Le cache de Magento, quand il est stocké en fichiers (réglage par défaut)	Il se reconstruit sans cesse ; il peut peser lourd sur un gros catalogue.
`var/session`	Les sessions des visiteurs, quand elles sont stockées en fichiers	Sur Debian et Ubuntu, le nettoyage automatique des sessions de PHP ne passe pas dans ce dossier.
`pub/media/catalog/product/cache`	Les images produits redimensionnées	Une version par taille d’image et par photo.
Racine du site, dossier personnel	Sauvegardes oubliées : `.sql`, `.sql.gz`, `.tar.gz`, `.zip`	Une copie de la base ou du site faite « juste avant une mise à jour », jamais retirée.
`/var/log` du serveur	Journaux du serveur web et du système	Trafic, attaques, erreurs : ils grossissent si leur propre rotation est mal réglée.
`/var/lib/mysql`	La base de données	Commandes, clients, journaux de la base, tables temporaires.

Quand Magento affiche « There has been an error processing your request » avec un numéro (« Error log record number »), ce numéro est le nom du rapport enregistré dans var/report. Une boutique qui affiche cette page des milliers de fois remplit ce dossier de milliers de fichiers.

Vérifier l’espace disque de Magento sans terminal

Vous n’avez pas besoin de compétences techniques pour faire un premier repérage.

Regardez l’espace utilisé dans l’espace client de votre hébergeur, s’il l’affiche, ou dans la carte Espace disque de Tocsin24 si le module est installé (voir plus bas).
Connectez-vous avec votre client FTP ou SFTP (FileZilla, Cyberduck, WinSCP) ou le gestionnaire de fichiers de votre hébergeur, avec les identifiants transmis par votre hébergeur ou votre agence.
Ouvrez le dossier de Magento, celui qui contient app, pub et var, et triez par taille. Cherchez les fichiers d’archive de plusieurs gigaoctets.
Ouvrez var, puis log et report. Des fichiers de log de plusieurs centaines de mégaoctets, ou un dossier report qui met longtemps à s’afficher, sont des pistes sérieuses.

/var/www/boutique

Nom	Taille	Modifié
..
app
pub
var
vendor
boutique-avant-mise-a-jour.sql.gz	9,4 Go	14/03/2026
sauvegarde-site.tar.gz	21 Go	02/02/2026
composer.json	4 Ko	12/09/2026

Exemple. Deux sauvegardes oubliées à la racine du site : 30 Go qui n’ont rien à faire sur le serveur de production.

Selon le logiciel, la taille d’un dossier n’apparaît pas dans la liste : une commande « Propriétés », « Infos » ou « Calculer la taille » la donne. Si votre client ne le propose pas, le message plus bas permet de demander l’analyse à votre hébergeur.

Libérer de la place sur Magento sans risque, et ce qu’il ne faut jamais toucher

Sans risque pour la boutique

Le cache de Magento. Dans l’administration, Système > Outils > Gestion du cache, bouton Purger le cache Magento. Adobe le présente comme l’équivalent de bin/magento cache:clean. Le cache se reconstruit tout seul.
Le cache des images produits. Même page, bouton Purger le cache des images catalogue : il retire les images redimensionnées de pub/media/catalog/product/cache. Les photos d’origine ne bougent pas. Contrepartie : Magento recalcule chaque image à la première visite, ce qui ralentit les pages et charge le serveur pendant un moment. À faire hors des heures d’affluence.
Les sauvegardes laissées sur le serveur. Récupérez-les sur un autre support, vérifiez la copie, puis retirez-les du serveur. La CNIL déconseille de toute façon de garder les sauvegardes sur le même système que les données.
Les gros logs. Videz-les plutôt que les supprimer, puis mettez en place la rotation des logs pour que le problème ne revienne pas.

À faire lire avant de retirer

Les rapports de var/report. Ce sont des traces d’erreurs. Faites-les lire par votre développeur : une erreur répétée des milliers de fois est un bug à corriger, et parfois le signe d’une attaque (voir que faire quand Magento 2 est piraté). Ensuite, les anciens rapports peuvent être archivés hors du serveur.

À ne jamais supprimer à la main

pub/media en dehors du dossier cache : ce sont vos photos, vos fichiers téléchargeables, vos images de pages.
app/etc, et en particulier env.php : la configuration et les accès de la boutique.
pub/static et generated en mode production : Magento sert les fichiers déployés et ne les recrée pas seul. Les supprimer impose un redéploiement.
var/session en pleine journée : chaque fichier est la session d’un visiteur. Les supprimer déconnecte vos clients et vos administrateurs.
Les fichiers de /var/lib/mysql : la base de données se nettoie avec ses propres commandes, jamais avec rm.

Vous n’êtes pas technique : le message à votre hébergeur

Trouver ce qui remplit un serveur prend quelques minutes à la personne qui y a accès. Voici un message prêt à envoyer :

Message à votre hébergeur ou à votre agence

Bonjour,

Le disque du serveur de notre boutique Magento est presque plein (ou plein). Pouvez-vous :

nous dire quels dossiers prennent le plus de place, y compris en nombre de fichiers (inodes) ;
retirer du serveur les sauvegardes qui y sont stockées, après en avoir gardé une copie ailleurs ;
vérifier la rotation des logs de Magento (var/log) et du serveur ;
regarder si une erreur se répète dans var/report ou var/log/exception.log ;
nous dire si le disque doit être agrandi, et à quel rythme il se remplit.

Merci de ne rien supprimer dans pub/media (hors pub/media/catalog/product/cache), app/etc ni dans la base de données sans nous en parler.

Merci.

Vous gérez le serveur : trouver ce qui remplit le disque

Les commandes ci-dessous ne font que lire. Elles sont écrites pour Debian ou Ubuntu, avec une boutique dans /var/www/boutique : remplacez le chemin par le vôtre.

Quel disque est plein, et de quoi ? df -h donne l’espace de chaque disque. df -i donne le nombre d’inodes, c’est-à-dire de fichiers possibles.

Terminal

df -h df -i

Repérez la ligne à 100 % ou presque, et notez son point de montage (/, /var, /home…).
Quel dossier prend la place ? Partez de la racine du disque plein, sans passer sur les autres disques (option -x), et triez par taille.

Terminal

Les plus gros dossiers du disque racine, du plus petit au plus gros sudo du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -n 15

Descendez ensuite dans le dossier le plus gros, en remplaçant / par son chemin. Si ncdu est installé, sudo ncdu -x / fait la même chose en version interactive.
Dans Magento, quels dossiers ?

Terminal, depuis le dossier de Magento

Taille des dossiers de var et de pub/media du -sh var/* pub/media/* 2>/dev/null | sort -h Taille du cache des images produits du -sh pub/media/catalog/product/cache
Les gros fichiers isolés, en particulier les sauvegardes oubliées :

Terminal

Fichiers de plus de 500 Mo sur le disque racine sudo find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null Archives et exports de base de plus de 100 Mo sous /var/www et /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 {} +
Les fichiers supprimés mais encore ouverts. Si df dit le disque plein alors que du ne trouve pas autant de fichiers, un programme garde ouvert un fichier déjà supprimé, souvent un gros log.

Terminal

sudo lsof +L1

La colonne SIZE/OFF donne la place retenue, la colonne COMMAND le programme. La place revient au redémarrage de ce programme (PHP-FPM, serveur web, consommateur de file de messages). lsof n’est pas toujours installé : sudo apt install lsof.
Les journaux du système et la base de données.

Terminal

Place prise par le journal du système (journald) journalctl --disk-usage Journaux du serveur web et du système sudo du -sh /var/log/* 2>/dev/null | sort -h Taille de la base de données sur le disque sudo du -sh /var/lib/mysql

Pour voir les tables les plus lourdes, cette requête en lecture seule, dans la base de Magento :

Client MySQL ou MariaDB

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

Libérer de la place côté serveur

Le cache de Magento, depuis le dossier de la boutique : bin/magento cache:flush. Adobe précise que flush vide tout le stockage du cache : s’il est partagé avec une autre application (un Redis commun, par exemple), préférez bin/magento cache:clean.
Le journal du système : sudo journalctl --vacuum-size=500M retire les plus anciennes archives jusqu’à repasser sous 500 Mo.
Les journaux binaires de la base (si la réplication ou la sauvegarde en continu les utilise) : ils se retirent avec PURGE BINARY LOGS, qui tient aussi à jour la liste des journaux. Jamais avec rm, et jamais avant d’avoir vérifié qu’aucun serveur répliqué ne les lit encore.

Terminal, depuis le dossier de Magento

Vider le cache de Magento bin/magento cache:flush Réduire le journal du système à 500 Mo sudo journalctl --vacuum-size=500M

Pour les développeurs

Sessions en fichiers sur Debian et Ubuntu. Adobe signale que session.gc_probability vaut 0 par défaut sur ces systèmes : PHP ne nettoie jamais lui-même les sessions expirées. Debian confie ce ménage à une tâche planifiée (/etc/cron.d/php, script /usr/lib/php/sessionclean), mais elle ne passe que dans le dossier session.save_path de PHP, pas dans var/session de Magento. Résultat : un fichier par visite, jamais effacé, jusqu’à l’épuisement des inodes. Adobe documente deux solutions : régler gc_probability, gc_divisor et gc_maxlifetime dans la section session de app/etc/env.php, ou stocker les sessions dans Redis.

Disque plein alors qu’il reste de la place : les inodes

Chaque fichier occupe une « fiche » sur le disque, appelée inode, en plus de son contenu. Le nombre de fiches est fixé quand le disque est formaté : sur ext4, le système le plus courant sous Debian, il ne se change plus ensuite. Un dossier qui contient des millions de tout petits fichiers peut donc épuiser les fiches bien avant l’espace.

Le symptôme trompe : df -h montre de la place libre, mais toute création de fichier échoue avec le même No space left on device.

Essayé sur un disque de test limité à 200 fichiers :

Résultat sur un disque de test

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

Le disque est vide à 0 %, mais ses inodes sont utilisés à 100 %. Pour trouver le dossier qui contient le plus de fichiers :

Terminal, depuis le dossier de Magento

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

Sur Magento, les suspects sont presque toujours var/session (sessions jamais nettoyées), var/report (une erreur répétée) et pub/media/catalog/product/cache.

Éviter que le disque de Magento se remplisse à nouveau

Mettez en place la rotation des logs de Magento : c’est la cause la plus fréquente. Notre guide pas à pas.
Sortez les sauvegardes du serveur et vérifiez qu’elles se restaurent. Une sauvegarde sur le même disque que la boutique ne protège de rien. Voir le point sur les sauvegardes de notre audit.
Faites corriger les erreurs qui se répètent dans var/report et exception.log.
Réglez le nettoyage des sessions si elles sont stockées en fichiers.
Surveillez la tendance, pas seulement le niveau : un disque à 70 % qui gagne 5 % par semaine est plus urgent qu’un disque à 85 % stable.

Ces vérifications font partie de l’entretien régulier d’une boutique Magento.

Tocsin24 vous prévient avant que le disque soit plein

Avec le module Magento installé, Tocsin24 relève l’espace libre du disque qui porte la boutique, et ceux de pub/media et var s’ils sont sur un autre disque. La carte Espace disque du tableau de bord passe à l’orange sous 20 % d’espace libre, au rouge sous 10 % ou sous 5 Go. Elle calcule aussi le rythme de remplissage sur deux semaines, et annonce « plein dans environ… ».

Au passage au rouge, Tocsin24 ouvre l’incident « Espace disque presque plein » et vous prévient. L’incident se clôt de lui-même quand la place revient. Tocsin24 signale aussi un fichier system.log ou exception.log de plus de 500 Mo.

Tocsin24 ne supprime rien sur votre serveur, et ne relève pas encore les inodes : un disque à court d’inodes reste à vérifier avec df -i.

Essayer gratuitement Voir la surveillance Magento 2

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: .

Écrans de l’application avec des valeurs d’exemple.

Questions fréquentes

Que veut dire « No space left on device » sur Magento ?

Que le système refuse d’écrire un fichier : le disque n’a plus de place, ou il n’a plus d’inodes, les « fiches » qui décrivent chaque fichier. Vérifiez les deux avec df -h et df -i, puis cherchez le dossier qui a grossi.

Puis-je vider le dossier var de Magento ?

Pas en entier. Le cache (var/cache, var/page_cache) se vide sans risque depuis l’administration ou avec bin/magento cache:flush. Les logs se vident ou se font tourner. Les rapports d’erreur se lisent puis s’archivent. Les sessions, elles, déconnectent vos clients si on les supprime.

Vider le cache des images produits est-il dangereux ?

Non pour les données : Magento régénère les images redimensionnées à la demande. Mais il les recalcule au fil des visites, ce qui ralentit les pages et charge le serveur. Faites-le hors des heures d’affluence.

J’ai supprimé un gros fichier et l’espace n’est pas revenu. Pourquoi ?

Un programme le garde sans doute ouvert, comme le cron ou le serveur web. La place n’est rendue qu’à l’arrêt de ce programme. La commande sudo lsof +L1 liste ces fichiers supprimés mais encore ouverts. La prochaine fois, videz le fichier au lieu de le supprimer.

Mon hébergeur doit-il agrandir le disque ?

Seulement si la croissance est normale : catalogue, médias, commandes. Si un dossier gonfle à cause d’une erreur, de logs sans rotation ou de sauvegardes laissées sur le serveur, agrandir ne fait que repousser la panne.

Cédric Michel

Cédric développe des boutiques Magento depuis 18 ans et détient la certification Adobe Commerce Developer Expert. Il a créé Tocsin24 pour surveiller la sécurité et la santé des boutiques Magento 2 et des sites WordPress.

Adobe Commerce Developer Expert
Vérifier la certification sur le site d’Adobe

Disque plein sur une boutique Magento : trouver ce qui prend la place