Comment nettoyer un serveur Linux en toute sécurité sans interrompre les services

Niveau : intermédiaire (systèmes de production)
Durée estimée : environ 30 minutes
Objectif : libérer de l'espace disque sur un serveur Linux en supprimant les paquets inutilisés, les anciens noyaux, les journaux obsolètes et les fichiers mis en cache, sans interrompre aucun service en cours d'exécution.

Ce guide suppose que vous disposez d'un accès SSH à un VPS de production ou assimilé. Ne l'exécutez pas à l'aveuglette sur des systèmes critiques sans avoir préalablement effectué de snapshots.

Introduction

Au fil du temps, même un VPS peu utilisé accumule du poids mort : paquets orphelins, noyaux obsolètes, gigaoctets de fichiers journaux non tournés et résidus de cache de paquets. Si rien n’est fait, un disque plein provoquera le plantage de votre serveur web, interrompra les écritures dans votre base de données et saturera votre file d’attente de courrier. Ce guide de nettoyage d’un système Linux vous explique comment nettoyer un serveur Linux en toute sécurité : en vérifiant d’abord l’utilisation du disque, en supprimant ce qui peut l’être sans risque, puis en vérifiant que vos services ont survécu au processus. Toutes les commandes présentées ici peuvent être exécutées en toute sécurité sur un serveur en production sans temps d’arrêt.

Ce que vous allez nettoyer

Catégorie	Exemples	Gains de place typiques
Paquets et dépendances inutilisés	Bibliothèques orphelines, pilotes remplacés	100 Mo - 2 Go
Anciens noyaux	Versions précédentes du noyau	200 Mo par noyau
Cache des paquets	Fichiers .deb / .rpm téléchargés	500 Mo - 5 Go
Journaux	Archives des journaux systemd	100 Mo - 10 Go
Fichiers journaux tournés	/var/log/*.gz, *.1	Variable

Prérequis

Avant de commencer, assurez-vous que les conditions suivantes sont remplies :

• Système d'exploitation : Ubuntu 24.04/26.04 LTS, Debian 13 ou AlmaLinux 10
• Accès : accès sudo ou root au serveur via SSH
• Connaissances requises : maîtrise du terminal Linux et des commandes de base en ligne de commande
• Sauvegarde : effectuez toujours un instantané ou une sauvegarde avant de supprimer en masse des paquets sur un serveur de production. Sur INTROSERV, vous pouvez commander une sauvegarde complète directement depuis l'Espace client.

Ne poursuivez pas si l’une des conditions suivantes est remplie :

• La partition/ est pleine à plus de 95 % : votre système peut déjà rencontrer des problèmes d’écriture. Résolvez d’abord la cause immédiate (recherchez et supprimez manuellement un seul fichier volumineux).
• Les services sont déjà hors service ou se comportent de manière inattendue. Identifiez la cause profonde avant de procéder au nettoyage afin d’éviter de perturber les services dont dépendent les systèmes Linux.
• Vous ne disposez d’aucune sauvegarde ni d’aucun instantané. Créez-en un au préalable : sur INTROSERV, cela prend moins de 2 minutes depuis l’Espace client.

Étape 1 : Vérifiez l’utilisation du disque avant de commencer

Niveau de risque : FAIBLE – Commandes en lecture seule uniquement. Aucune modification n’est effectuée.

Ne procédez jamais à un nettoyage à l’aveuglette. Commencez par identifier ce qui occupe réellement de l’espace.

1.1 Vérifiez l'utilisation globale du disque

Exécutez la commande `df` pour vérifier l'utilisation du disque au niveau du système de fichiers :

df -h

Résultat attendu :

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   34G  3.8G  90% /
tmpfs           1.0G     0  1.0G   0% /dev/shm

Une partition / dont l'utilisation dépasse 80 % est un signe d'alerte. Au-delà de 95 %, les services commenceront à présenter des dysfonctionnements.

1.2 Identifiez les éléments qui occupent le plus d’espace

Utilisez la commande `du` pour explorer les répertoires. Commencez par la racine et descendez progressivement :

sudo du -h --max-depth=1 / 2>/dev/null | sort -rh | head -20

Cela affiche les 20 répertoires les plus volumineux sous /. Les coupables habituels sont /var/log, /var/cache, /usr et /home.

Affinez encore la recherche :

sudo du -h --max-depth=1 /var/log | sort -rh | head -10

1.3 Vérifiez l'utilisation des inodes

L'espace disque n'est pas la seule contrainte. Les inodes permettent de compter le nombre de fichiers. Une partition peut disposer d'espace libre mais être à court d'inodes, ce qui entraînera également l'échec des écritures.

df -i

Résultat attendu :

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1      2621440 210543 2410897    9% /

Si IUse% est supérieur à 80 %, vous avez probablement un répertoire contenant des dizaines de milliers de petits fichiers — souvent une file d’attente de courrier, un répertoire de session ou un cache PHP. Utilisez du --inodes pour l’identifier :

sudo du --inodes -h --max-depth=2 /var | sort -rh | head -10

Étape 2 : Supprimez les paquets et les dépendances inutilisés

Niveau de risque : MOYEN — La suppression de paquets est réversible via l’historique du gestionnaire de paquets, mais vérifiez la liste avant de valider.

Les paquets inutilisés sont les éléments les plus sûrs à supprimer. Ils occupent de l’espace sur le disque, ne servent aucun processus en cours d’exécution et, dans certains cas, comportent des vulnérabilités CVE non corrigées.

2.1 Ubuntu / Debian - apt autoremove

La commande `apt autoremove ` supprime les paquets qui ont été installés en tant que dépendances mais qui ne sont plus utilisés par aucun autre élément :

sudo apt autoremove --purge -y

L'option --purge supprime également les fichiers de configuration restants. Sans elle, le binaire du paquet est supprimé, mais les fichiers de configuration restent en place.

Résultat attendu :

The following packages will be REMOVED:
  libfoo1 libbar2 old-driver-utils ...
0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.

2.2 AlmaLinux / RHEL - dnf autoremove

sudo dnf autoremove -y

Sur les anciens systèmes RHEL 7 / CentOS 7, utilisez ` yum autoremove` :

sudo yum autoremove -y

2.3 Nettoyer le cache des paquets

Après les mises à jour et les installations, les gestionnaires de paquets stockent localement les fichiers d'archives téléchargés. Vous pouvez les supprimer en toute sécurité une fois l'installation terminée.

Ubuntu / Debian :

sudo apt clean

Cette commande supprime tous les fichiers .deb mis en cache dans le répertoire /var/cache/apt/archives/. Pour ne supprimer que les paquets qui ne sont plus disponibles dans le dépôt (versions obsolètes) :

sudo apt autoclean

AlmaLinux / RHEL :

sudo dnf clean all

Résultat attendu :

16 files removed

Étape 3 : Supprimer les anciens noyaux

Niveau de risque : ÉLEVÉ – La suppression d’un noyau incorrect rendra le serveur impossible à démarrer après le prochain redémarrage. Vérifiez toujours la commande ` uname -r ` avant de continuer.

Chaque mise à jour du noyau conserve la version précédente en place par mesure de sécurité. Après avoir vérifié que votre serveur fonctionne correctement avec le nouveau noyau, vous pouvez supprimer les anciens noyaux en toute sécurité ; chacun libère généralement entre 200 et 400 Mo.

3.1 Vérifier quel noyau est en cours d’exécution

Ne supprimez jamais le noyau sur lequel vous êtes actuellement démarré :

uname -r

Résultat attendu :

5.15.0-105-generic

3.2 Lister tous les noyaux installés

Ubuntu / Debian :

dpkg -l | grep linux-image | awk '{print $2}'

Résultat attendu :

linux-image-5.15.0-100-generic
linux-image-5.15.0-105-generic
linux-image-generic

Le méta-paquet ne doit pas être supprimé : il permet de suivre le noyau actuellement recommandé :

• Ubuntu : linux-image-generic
• Debian : linux-image-amd64
• AlmaLinux : aucun méta-paquet n'est utilisé ; le système s'appuie sur l'option ` installonly_limit ` de dnf.

Ne supprimez que les paquets spécifiques versionnés qui ne correspondent pas à votre noyau actuel.

AlmaLinux / RHEL :

rpm -q kernel

Résultat attendu :

kernel-5.14.0-284.11.1.el9_2.x86_64
kernel-5.14.0-362.8.1.el9_3.x86_64

3.3 Supprimer les anciens noyaux

Ubuntu / Debian - méthode automatique :

La commande `apt autoremove` de l'étape 2 gère déjà les anciens noyaux sous Ubuntu si le paquet `linux-image-generic` est installé. Vous pouvez également les cibler explicitement. Remplacez la version par celle que vous souhaitez supprimer (et non celle actuellement en cours d'exécution) :

sudo apt remove --purge linux-image-5.15.0-100-generic -y

AlmaLinux / RHEL :

Le gestionnaire de paquets dnf conserve un nombre configurable d'anciens noyaux. Définissez la limite dans /etc/dnf/dnf.conf:

sudo nano /etc/dnf/dnf.conf

Ajoutez ou modifiez la ligne :

installonly_limit=2

Puis exécutez :

sudo dnf remove $(dnf repoquery --installonly --latest-limit=-1 -q)

Cela supprime tous les noyaux sauf les deux plus récents.

Étape 4 : Nettoyage des journaux

Niveau de risque : FAIBLE – Supprime uniquement les entrées de journal archivées. Les services en cours d’exécution ne sont pas affectés.

systemd-journald collecte les journaux de tous les services du système. Par défaut, sa taille peut augmenter indéfiniment jusqu’à ce qu’elle atteigne la limite du disque – ou que cette limite soit épuisée.

4.1 Vérifier la taille actuelle du journal

journalctl --disk-usage

Résultat attendu :

Archived and active journals take up 2.3G in the filesystem.

4.2 Nettoyer le journal

Pour ne conserver que les journaux des 7 derniers jours :

sudo journalctl --vacuum-time=7d

Pour ne conserver que les 500 Mo les plus récents :

sudo journalctl --vacuum-size=500M

Résultat attendu :

Deleted archived journal /var/log/journal/.../[email protected] (64.0M).
Vacuuming done, freed 1.8G of archived journals from /var/log/journal/.

4.3 Empêcher toute augmentation future de la taille du journal

Créez un fichier de configuration à insérer pour limiter définitivement la taille du journal (sous AlmaLinux 10, le fichier de configuration principal n'est de toute façon pas présent dans /etc/ par défaut, ce qui fait de cette méthode l'approche standard) :

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/99-size.conf <<EOF
[Journal]
SystemMaxUse=500M
MaxRetentionSec=30day
EOF

Appliquer la modification :

sudo systemctl restart systemd-journald

Étape 5 : Nettoyage des fichiers journaux rotés et anciens

Niveau de risque : MOYEN – Seules les archives compressées sont supprimées. Ne touchez pas aux fichiers sans extension .gz ni suffixe numérique.

Les journaux d’application situés dans /var/log/ sont gérés par logrotate. Normalement, logrotate conserve un nombre défini de copies tournées et les compresse automatiquement. Si logrotate a été mal configuré ou ne s’exécute pas, vous pouvez constater une accumulation importante de fichiers .gz, .1, .2.

5.1 Rechercher les fichiers journaux volumineux

find /var/log -type f -name "*.gz" -o -name "*.log" | xargs du -sh 2>/dev/null | sort -rh | head -20

Ou plus simplement :

sudo du -h /var/log | sort -rh | head -20

5.2 Supprimer les anciennes archives de journaux compressées

Les fichiers journaux compressés et tournés (.gz) peuvent être supprimés en toute sécurité. Il s’agit d’archives de fichiers journaux déjà fermés.

Commencez par prévisualiser ce qui sera supprimé : exécutez la commande sans l'option -delete pour afficher la liste :

sudo find /var/log -name "*.gz" -mtime +30

Si le résultat vous convient, lancez la suppression proprement dite :

sudo find /var/log -name "*.gz" -mtime +30 -delete

Cela supprime les archives de journaux .gz datant de plus de 30 jours.

5.3 Vérifier que logrotate est correctement configuré

Vérifiez quels services disposent de configurations logrotate :

ls /etc/logrotate.d/

Exécutez logrotate manuellement en mode débogage pour vérifier qu’il fonctionne sans erreur :

sudo logrotate -d /etc/logrotate.conf

L'option -d correspond à un test sans modification : rien n'est modifié, mais vous verrez exactement ce qui se passerait. Si un service est absent du répertoire /etc/logrotate.d/, créez une configuration pour celui-ci. Consultez le guide de rotation des journaux pour obtenir des instructions complètes sur la configuration de logrotate.

Étape 6 : Supprimer les fichiers temporaires

Niveau de risque : MOYEN – Les sessions PHP et les caches d’application affectent les utilisateurs actifs. Effectuez un aperçu avant de supprimer.

6.1 Nettoyer /tmp

Le répertoire /tmp est vidé au redémarrage par la plupart des distributions. Si votre serveur fonctionne depuis des mois, il se peut qu’il ait accumulé des fichiers temporaires volumineux :

du -sh /tmp

Pour supprimer les fichiers datant de plus de 7 jours, prévisualisez d'abord :

sudo find /tmp -type f -mtime +7

Si la liste vous semble sans risque, lancez la suppression :

sudo find /tmp -type f -mtime +7 -delete

6.2 Nettoyer les caches d'application

De nombreuses applications créent leurs propres caches. Vérifiez ces emplacements courants (remarque : assurez-vous que ces répertoires existent sur votre système ; sur un système vierge, ils peuvent ne pas être présents et vous obtiendrez une erreur « Fichier ou répertoire introuvable ») :

# PHP session files (often forgotten, if installed)
sudo du -sh /var/lib/php/sessions/

# Pip / Python package caches (if running as root and installed)
sudo du -sh /root/.cache/pip/

# npm cache (if node is installed system-wide)
sudo du -sh /root/.npm/

Vous pouvez purger ces répertoires en toute sécurité si l’application ne les utilise pas activement.

Étape 7 : Vérifier que les services sont toujours en cours d’exécution

Niveau de risque : FAIBLE – Vérification en lecture seule. Effectuez cette opération après chaque étape, et pas seulement à la fin.

Après chaque cycle de nettoyage, vérifiez que vos services sont toujours opérationnels. Effectuez cette vérification avant de fermer votre session SSH.

7.1 Vérification de l'état des services critiques

Vérifiez uniquement les services qui sont effectivement installés sur votre serveur (sur un système vierge, la vérification de nginx ou de mysql renverra le message « Unité introuvable »).

Ubuntu / Debian :

systemctl status nginx
systemctl status mysql
systemctl status ssh

AlmaLinux / RHEL :

systemctl status nginx
systemctl status mysqld
systemctl status sshd

Chacun devrait afficher « Active : active (running) ». Si l’un d’entre eux affiche « failed » ou « inactive », vérifiez ses journaux :

journalctl -u nginx --since "10 minutes ago"

7.2 Vérifier que l'utilisation du disque s'est améliorée

df -h

Comparez la colonne « Use% » avec ce que vous avez observé à l’étape 1. La variation devrait correspondre à l’espace que vous avez libéré.

7.3 Testez votre application

Si vous exploitez un serveur web, envoyez une requête de test :

curl -I http://localhost

Résultat attendu :

HTTP/1.1 200 OK
Server: nginx/1.24.0

Un code 200 OK confirme que nginx gère le trafic normalement.

Dépannage

La commande `df` n’indique aucune amélioration après la suppression des paquets

La suppression d’un paquet libère immédiatement de l’espace. Si `df` n’affiche aucun changement, cela signifie que les fichiers sont toujours ouverts. Recherchez les fichiers ouverts mais supprimés :

sudo lsof | grep deleted

Redémarrez le service qui maintient le fichier ouvert et l'espace sera récupéré.

La commande `apt autoremove` propose de supprimer un élément qui semble important

Lisez attentivement la liste. Si vous voyez le nom d’un paquet que vous reconnaissez comme une dépendance d’un service en cours d’exécution, appuyez sur N et vérifiez. Exécutez ` apt-cache rdepends <paquet> ` pour voir ce qui en dépend.

`journalctl --vacuum-time` n'apporte aucun changement

Il se peut que le journal soit déjà plus petit que la taille cible. Vérifiez avec `journalctl --disk-usage`. Assurez-vous également que le journal est persistant : vérifiez que le répertoire `/var/log/journal/` existe. Si seul le répertoire `/run/log/journal/` existe, le journal est stocké en mémoire vive (RAM) et s'efface automatiquement au redémarrage.

Le service échoue après `apt autoremove`

Exécutez `systemctl status <service> ` et vérifiez l’erreur. Si une bibliothèque partagée a été supprimée, réinstallez le paquet qui la fournit :

sudo apt install --fix-broken

Épuisement des inodes malgré de l'espace disque disponible

Identifiez le répertoire contenant le plus grand nombre de fichiers :

find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -10

Causes courantes : les files d’attente de courrier dans /var/spool/mail, les sessions PHP dans /var/lib/php/sessions, ou une tâche cron incontrôlée créant des fichiers temporaires.

Restauration

La plupart des opérations de nettoyage sont irréversibles : les fichiers supprimés sont perdus. C’est pourquoi l’étape de sauvegarde décrite dans la section « Conditions préalables » est obligatoire.

Pour la suppression de paquets en particulier, vous pouvez réinstaller ce qui a été supprimé :

Ubuntu / Debian :

sudo apt install <package-name>

AlmaLinux / RHEL :

sudo dnf install <package-name>

Pour consulter l'historique des éléments supprimés au cours de la session en cours :

Ubuntu / Debian :

cat /var/log/dpkg.log | grep "^$(date +%Y-%m-%d)" | grep " remove "

AlmaLinux / RHEL :

sudo dnf history list
sudo dnf history undo last

La commande `dnf history undo last` réinstalle les paquets supprimés lors de la dernière transaction — un outil de récupération utile si la fonction « autoremove » est allée plus loin que prévu.

Conclusion

Le nettoyage d’un serveur Linux sans interruption de service repose sur trois principes : commencer par évaluer la situation, ne supprimer que ce que le système confirme comme étant inutilisé, et vérifier les services après chaque étape. Exécutez les commandes `df -h ` et `du` avant toute intervention. Utilisez ` apt autoremove ` / ` yum autoremove ` pour les paquets inutilisés, ` journalctl --vacuum-time ` pour le nettoyage des journaux, et `find /var/log -name "*.gz" ` pour les anciennes archives tournées. Ne supprimez les anciens noyaux qu’après avoir vérifié que la commande ` uname -r ` correspond bien à celui que vous conservez. Et vérifiez toujours ` systemctl status ` avant de fermer le terminal.

Pour un VPS INTROSERV, maintenir l'utilisation du répertoire / en dessous de 80 % est un objectif raisonnable : cela laisse de la marge pour les pics de journaux et les mises à jour de paquets sans intervention d'urgence. Si l'espace disque est un problème récurrent, envisagez de redimensionner le stockage de votre VPS directement depuis l'Espace client INTROSERV.

Version du document : 1.0
Dernière mise à jour : mai 2026
Responsable : Équipe de documentation technique