Diagnostiquer un manque d’inodes sur un VPS Linux

Un VPS peut afficher encore de l’espace libre sur son SSD tout en refusant de créer un fichier. Dans ce cas, le problème vient parfois des inodes et non de la capacité en gigaoctets. Ce guide aide un administrateur à diagnostiquer un serveur virtuel Linux accessible en SSH, puis à nettoyer sans supprimer les données utiles.

Comprendre les inodes

Un système de fichiers associe des métadonnées à chaque fichier et répertoire. Ces entrées sont appelées inodes. La capacité du volume et le nombre d’inodes sont deux limites différentes : un volume peut donc avoir des gigaoctets disponibles alors que toutes ses entrées sont consommées. Les petits fichiers, les journaux et les caches peuvent accélérer cette saturation.

Les symptômes possibles sont une erreur de création de fichier, un service qui ne démarre plus ou un serveur de jeu qui ne parvient plus à écrire ses journaux. Ces signes ne suffisent pas à conclure : il faut mesurer les deux ressources, comme on le ferait pour le CPU, la RAM et l’espace du disque.

Vérifier l’espace et les inodes

Connectez-vous en SSH avec un compte d’administration sur votre distribution Linux, par exemple Debian ou Ubuntu. Utilisez un compte root seulement lorsque c’est nécessaire et conservez vos sauvegardes avant une opération de maintenance :

df -h
df -i

Dans la sortie de df -i, regardez la colonne d’utilisation et le point de montage. Une valeur proche de 100 % confirme que le volume manque d’inodes. Si les inodes sont disponibles mais que df -h indique un volume plein, le diagnostic est différent et il faut rechercher les fichiers volumineux. L’adresse IP, le mot de passe SSH et les clés privées ne doivent jamais être publiés dans un rapport.

Localiser les répertoires qui contiennent trop de fichiers

Commencez par les emplacements adaptés à votre installation. Cette commande compte les entrées de premier niveau du système de fichiers racine :

for d in /*; do
  [ -d "$d" ] || continue
  printf "%s : " "$d"
  find "$d" -xdev -mindepth 1 -maxdepth 1 2>/dev/null | wc -l
done

Descendez ensuite dans le répertoire suspect. Sur un serveur de jeu, inspectez notamment le dossier du serveur, les journaux et les sauvegardes, sans supprimer à l’aveugle. Pour repérer les sous-répertoires comportant beaucoup d’entrées :

find /chemin/du/serveur -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -nr | head -20

Adaptez le chemin à votre installation. La recherche avec -xdev évite de traverser un autre système de fichiers monté à cet endroit. Un panneau de contrôle ou un outil d’infogérance peut afficher la consommation, mais la mesure avec df reste utile pour confirmer le point de montage réellement utilisé.

Nettoyer sans interrompre le serveur

Identifiez d’abord la politique de conservation des journaux, des fichiers temporaires et des backups. Arrêtez proprement le service concerné avant de supprimer un fichier encore ouvert, et conservez une sauvegarde récente si elle est nécessaire à votre reprise. Ne supprimez jamais un répertoire système ou un fichier de configuration uniquement parce qu’il apparaît dans un comptage.

Les actions prudentes consistent à archiver ou purger les journaux selon leur rotation prévue, retirer les caches régénérables et supprimer uniquement les sauvegardes expirées selon une règle connue. Après chaque action, contrôlez à nouveau :

df -h
df -i

Si un fichier supprimé continue d’occuper de l’espace, un processus peut encore le garder ouvert. Identifiez alors les fichiers supprimés ouverts avec un outil d’administration adapté, puis redémarrez uniquement le service concerné selon votre procédure de maintenance. Vérifiez aussi que le firewall et les permissions n’empêchent pas le service de redémarrer.

Prévenir une nouvelle saturation

Surveillez les inodes en plus de l’espace disque. Fixez un seuil d’alerte, vérifiez régulièrement les journaux et évitez les scripts qui créent un fichier par événement sans rotation ni limite. Une rotation des logs, une rétention documentée des sauvegardes et un contrôle après mise à jour réduisent le risque.

Sur un serveur virtuel, la RAM, le CPU et les I/O du SSD influencent aussi le comportement général, mais ils ne remplacent pas le contrôle des inodes. Un hébergeur peut fournir des métriques ou un panel, sans que cela dispense de vérifier le système de fichiers depuis Linux. Un monitoring utile suit au minimum l’espace de stockage, les inodes, la charge CPU, la mémoire et l’état des services.

Dans une offre VPS, la machine virtuelle partage une infrastructure avec d’autres serveurs virtuels, tandis qu’un serveur physique dédié réserve ses ressources à un seul client. Cette différence de virtualisation ne change pas la commande df -i : les inodes restent une limite du système de fichiers monté dans votre environnement.

Le choix d’un serveur dédié virtuel ou d’un VPS cloud peut modifier les ressources disponibles, la bande passante, le processeur et les possibilités de redondance, mais aucun de ces paramètres ne crée automatiquement des inodes supplémentaires. Le système d’exploitation, le type de stockage et la manière dont le volume est monté restent à vérifier avant de conclure qu’un changement d’offre résoudra le problème.

Pour un serveur de jeu, documentez les chemins de données, les commandes d’arrêt et la durée de conservation. Cette documentation rend le nettoyage plus sûr lors d’une alerte et facilite une migration vers un autre VPS Linux si la charge évolue. Elle aide aussi à évaluer si une offre VPS, un serveur dédié ou une architecture cloud convient à la quantité de données et au niveau de haute disponibilité recherchés.

Quand demander de l’aide

Demandez une analyse avant toute suppression si le point de montage est inconnu, si plusieurs services partagent le volume ou si les fichiers appartiennent à un conteneur. Pour préparer votre diagnostic, notez les sorties de df -h, df -i, le chemin concerné et l’heure d’apparition du problème, sans transmettre de secret.

Vous pouvez aussi comparer ce diagnostic avec notre guide sur la limite de fichiers ouverts : cette limite est différente des inodes, même si les symptômes peuvent se ressembler. Pour les autres pannes réseau, consultez le diagnostic d’un VPS inaccessible.

Pour approfondir l’exploitation, consultez aussi nos guides sur Docker sur un VPS, la sécurisation d’un serveur et les sauvegardes Pterodactyl.