Skip to content
VDS · Dépannage

Espace disque épuisé

Comment trouver rapidement ce qui remplit le disque, libérer des gigaoctets en toute sécurité, et comprendre les pièges : fichiers ouverts supprimés et inodes épuisés.

Mis à jour le 23 août 2026

Un disque plein casse tout d'un coup : la base de données cesse d'accepter les écritures, le site renvoie des erreurs, journalctl refuse de fonctionner, et parfois même SSH ne vous laisse plus entrer, car il ne reste plus rien pour écrire le journal de session. Vous devez agir vite et dans l'ordre.

Vérifier

df -h
df -i

La première commande affiche l'espace, la seconde les inodes. Des inodes pleins produisent la même erreur « No space left on device » même avec des gigaoctets libres : cela se produit lorsqu'un répertoire a accumulé des millions de minuscules fichiers (sessions PHP, cache, files d'attente).

Vous pouvez aussi voir l'espace utilisé dans le panneau à l'adresse /hosting/vds/m/<id> — l'anneau de l'onglet « Aperçu ». Il est rempli à partir des données transmises par le qemu-guest-agent ; si l'agent a été supprimé, l'anneau reste vide et le panneau affiche à la place la commande d'installation.

Trouver le coupable

du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -15
du -xh --max-depth=1 /var 2>/dev/null | sort -h | tail -15
ncdu -x /                     # apt install ncdu, interactive
find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null

L'option -x limite la recherche à un seul système de fichiers et l'empêche de s'aventurer dans /proc et les répertoires montés.

Coupables typiques : les journaux dans /var/log, le cache des paquets dans /var/cache, les images et volumes Docker dans /var/lib/docker, les dumps de base de données, les archives oubliées dans /root et /tmp, les fichiers des anciennes versions de l'application.

Libérer de l'espace

journalctl --vacuum-size=200M
apt clean                                   # Debian, Ubuntu
dnf clean all                               # AlmaLinux, CentOS Stream
docker system prune -af --volumes           # careful: will remove unused volumes
find /tmp -type f -mtime +7 -delete

Pour plafonner le journal de façon permanente, modifiez /etc/systemd/journald.conf (SystemMaxUse=300M) ; consultez l'article journaux systemd pour plus de détails. Pour les fichiers applicatifs, configurez logrotate : sans rotation, un simple app.log peut facilement atteindre des dizaines de gigaoctets.

Piège : un fichier supprimé mais toujours ouvert

Vous avez supprimé un journal gigantesque, mais df affiche les mêmes chiffres. Tant qu'un processus garde le fichier ouvert, l'espace n'est pas restitué.

lsof +L1 | head -20

La bonne solution consiste à redémarrer le service qui détient le fichier (systemctl restart nginx), ou à tronquer le fichier sans le supprimer :

: > /var/log/nginx/access.log

Piège : plus d'inodes

df -i
find /var/www -xdev -type d -printf '%h\n' | sort | uniq -c | sort -rn | head

Cherchez un répertoire contenant des centaines de milliers de fichiers et nettoyez-le par tranches pour ne pas faire tomber la machine :

find /var/lib/php/sessions -type f -mtime +2 -delete

S'il n'y a plus du tout d'espace

Lorsque le disque est plein à 100 % et que le système est à peine réactif, connectez-vous via l'onglet « Console » du panneau, libérez au moins une centaine de mégaoctets (journalctl --vacuum-size=50M fonctionne presque toujours), puis poursuivez le dépannage normalement. Dans un cas vraiment critique, le disque de secours vous aidera : la machine démarre sur SystemRescue, votre disque apparaît sous /dev/sda, et vous le montez et nettoyez depuis l'extérieur.

Pour éviter que cela ne se reproduise

  • Une alerte au seuil de 85 % — voir Alertes d'indisponibilité du site.
  • Faites tourner tous les journaux applicatifs, pas seulement ceux du système.
  • Envoyez immédiatement les dumps de base de données et les archives hors du serveur, au lieu de les garder dans /root.
  • S'il ne reste plus rien à nettoyer et que vos données continuent de croître, passez à un palier avec un disque plus grand : 40, 80, 120, 160, 200 et 250 GB. Mises à niveau uniquement : les disques ne peuvent pas être réduits, et les rétrogradations ne sont pas disponibles.

Ne supprimez pas des fichiers dans /var/lib et /usr au hasard : c'est là que résident les données des bases de données et les paquets système. Déterminez d'abord à quoi appartient un répertoire, et seulement ensuite nettoyez-le.