> ## Documentation Index
> Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Disque plein sur un VPS Linux : No space left on device

> Disque plein sur votre VPS Linux ? Trouvez ce qui remplit l'espace et libérez-le sans casser le serveur : journal, logs, Docker, binlogs. Guide OnetSolutions.

*Publié le 14 novembre 2026*

« No space left on device » : votre VPS Linux a rempli son disque. À partir de là, tout ce qui écrit échoue. La base de données refuse les requêtes, PHP ne crée plus de sessions, une mise à jour s'arrête au milieu, le journal perd des lignes.

La bonne nouvelle : l'espace se récupère presque toujours sans rien casser, à condition de savoir où il est parti. Ce guide suit l'ordre d'un diagnostic, sur Debian, Ubuntu, AlmaLinux et Rocky Linux. Chaque section donne le problème, la commande qui le règle et la vérification.

## Où part l'espace disque d'un VPS

Récapitulatif des sources les plus fréquentes, établi le 14 novembre 2026 :

| Source | Mesurer | Libérer sans risque |
| - | - | - |
| Fichiers supprimés encore ouverts | `lsof -nP +L1` | Redémarrer le service qui les tient |
| Journal systemd | `journalctl --disk-usage` | `journalctl --vacuum-size=` |
| Logs applicatifs | `du -sh /var/log/*` | `truncate -s 0`, puis logrotate |
| Cache de paquets | `du -sh /var/cache/apt` ou `/var/cache/dnf` | `apt clean`, `dnf clean all` |
| Anciens noyaux | `dpkg -l 'linux-image*'`, `rpm -q kernel` | `apt autoremove --purge`, `dnf remove --oldinstallonly` |
| Docker | `docker system df` | `docker system prune` |
| Binlogs MySQL / MariaDB | `SHOW BINARY LOGS;` | `PURGE BINARY LOGS BEFORE ...` |
| Inodes épuisés | `df -i` | Supprimer les petits fichiers en masse (sessions, cache) |

## Avant de nettoyer : un snapshot

Un nettoyage se fait vite, une suppression de trop aussi. Prenez un [snapshot](https://help.onetsolutions.net/fr/vps/snapshot) depuis la console avant de toucher aux binlogs, aux volumes Docker ou aux noyaux. Vous gardez un point de retour en un clic.

Les [sauvegardes](https://help.onetsolutions.net/fr/vps/backup) restent votre protection de fond.

## Diagnostiquer un disque plein

### Quel système de fichiers est plein

```bash theme={null}
# Taille, occupation et type de chaque système de fichiers
df -hT -x tmpfs -x devtmpfs
```

Repérez la ligne à 100 % et son point de montage (`Mounted on`). Le plus souvent, c'est `/`.

### Blocs ou inodes

Un disque peut être plein sans que `df -h` le montre. Chaque fichier consomme un inode, et leur nombre est fixé à la création du système de fichiers sur ext4. Des millions de petits fichiers les épuisent avant l'espace.

```bash theme={null}
# Colonne IUse% : 100 % = plus aucun fichier ne peut être créé
df -i -x tmpfs -x devtmpfs
```

Si `IUse%` est à 100 %, trouvez le répertoire qui contient le plus de fichiers :

```bash theme={null}
# Nombre d'inodes par répertoire, sans sortir de /
sudo du --inodes -x -d 1 / | sort -n | tail -n 10
```

Descendez ensuite d'un niveau dans le répertoire en tête (`sudo du --inodes -x -d 1 /var | sort -n | tail`). Les coupables habituels : sessions PHP, cache applicatif, file d'attente de messagerie.

### Trouver les gros répertoires

```bash theme={null}
# Les 15 plus gros répertoires de premier niveau, sans sortir de /
sudo du -xh -d 1 / 2>/dev/null | sort -h | tail -n 15
```

L'option `-x` est essentielle : elle reste sur le système de fichiers de `/` et ne compte pas les autres montages.

Pour naviguer plus vite, `ncdu` fait la même chose de façon interactive :

```bash theme={null}
# Debian, Ubuntu
sudo apt install ncdu
# AlmaLinux, Rocky (dépôt EPEL)
sudo dnf install epel-release && sudo dnf install ncdu

sudo ncdu -x /
```

Quand le disque est plein à 100 %, l'installation peut échouer. Commencez alors par `apt clean` ou `dnf clean all` (plus bas) pour gagner un peu de place.

## Fichiers supprimés mais toujours ouverts

**Problème.** Vous avez supprimé un gros log avec `rm`, et `df` n'a pas bougé. Le fichier n'existe plus dans l'arborescence, mais un processus le garde ouvert : l'espace n'est rendu qu'à la fermeture. C'est aussi le cas quand `du` donne un total bien inférieur à `df`.

**Solution.** Listez les fichiers dont le dernier lien a été supprimé :

```bash theme={null}
# Installer lsof si besoin : apt install lsof / dnf install lsof
sudo lsof -nP +L1
```

La colonne `COMMAND` donne le processus, `SIZE/OFF` la taille. Redémarrez le service concerné :

```bash theme={null}
sudo systemctl restart nginx
```

Si le service ne peut pas être redémarré tout de suite, videz le fichier par son descripteur. Le `PID` et le `FD` (sans la lettre finale, `4w` devient `4`) viennent de la sortie de `lsof` :

```bash theme={null}
sudo truncate -s 0 /proc/1234/fd/4
```

**Vérification.** `sudo lsof -nP +L1` ne liste plus le fichier, et `df -h /` affiche l'espace rendu.

## Réduire le journal systemd

**Problème.** `/var/log/journal` occupe plusieurs gigaoctets.

**Solution.** Mesurez, puis réduisez :

```bash theme={null}
# Espace occupé par le journal
journalctl --disk-usage

# Garder au plus 500 Mo d'archives
sudo journalctl --vacuum-size=500M

# Ou garder seulement les deux dernières semaines
sudo journalctl --vacuum-time=2weeks
```

Le nettoyage ne touche que les fichiers archivés. Pour qu'il tienne dans le temps, fixez un plafond. Par défaut, journald s'autorise 10 % du système de fichiers. La page de manuel `journald.conf` recommande un fichier à part dans `/etc/systemd/journald.conf.d/` plutôt que de modifier le fichier principal :

```bash theme={null}
sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/50-taille.conf >/dev/null <<'EOF'
[Journal]
SystemMaxUse=500M
EOF
sudo systemctl restart systemd-journald
```

**Vérification.** `journalctl --disk-usage` reste sous la valeur choisie dans les jours qui suivent.

## Vider et faire tourner les logs applicatifs

**Problème.** Un fichier de `/var/log` ou d'une application grossit sans fin.

**Solution.** Trouvez-le :

```bash theme={null}
sudo du -xah /var/log 2>/dev/null | sort -h | tail -n 15
```

Pour le vider sans couper le service qui écrit dedans, utilisez `truncate` plutôt que `rm` :

```bash theme={null}
sudo truncate -s 0 /var/log/monapp/app.log
```

Puis donnez-lui une rotation. logrotate est installé sur les quatre distributions et lit `/etc/logrotate.d/` :

```bash theme={null}
sudo tee /etc/logrotate.d/monapp >/dev/null <<'EOF'
/var/log/monapp/*.log {
    daily
    rotate 7
    # Rotation anticipée si le fichier dépasse 100 Mo
    maxsize 100M
    compress
    delaycompress
    missingok
    notifempty
    # Pour une application qui ne rouvre pas son fichier de log
    copytruncate
}
EOF
```

`copytruncate` copie le fichier puis le vide sur place : l'application continue d'écrire au même endroit. Si elle sait rouvrir ses logs sur signal, préférez un bloc `postrotate` qui le lui envoie.

**Vérification.** Le mode débogage simule la rotation sans rien modifier :

```bash theme={null}
sudo logrotate -d /etc/logrotate.d/monapp
```

## Vider le cache des paquets

**Problème.** Les paquets téléchargés lors des mises à jour restent sur le disque.

**Solution.**

```bash theme={null}
# Debian, Ubuntu : supprime les .deb de /var/cache/apt/archives
sudo apt clean

# AlmaLinux, Rocky : supprime métadonnées et paquets en cache
sudo dnf clean all
```

Les deux commandes sont sans risque : les paquets seront retéléchargés si besoin.

**Vérification.** `sudo du -sh /var/cache/apt` ou `sudo du -sh /var/cache/dnf` est revenu à quelques mégaoctets.

## Supprimer les anciens noyaux

**Problème.** Chaque mise à jour du noyau en installe une nouvelle version à côté des précédentes, avec ses modules dans `/lib/modules` et son image dans `/boot`.

**Solution sur Debian et Ubuntu.** Simulez d'abord, puis supprimez :

```bash theme={null}
# Liste ce qui serait retiré, sans rien faire
sudo apt autoremove --purge -s

sudo apt autoremove --purge
```

APT protège le noyau en cours d'exécution et le plus récent. Relisez quand même la liste : `autoremove` retire aussi les dépendances devenues orphelines.

**Solution sur AlmaLinux et Rocky.** dnf garde un nombre fixe de versions des paquets « installonly », dont le noyau, réglé par `installonly_limit` dans `/etc/dnf/dnf.conf`. Pour retirer les versions en trop dès maintenant :

```bash theme={null}
# Noyaux installés
rpm -q kernel

# Retire les anciennes versions au-delà de installonly_limit,
# jamais le noyau en cours d'exécution
sudo dnf remove --oldinstallonly kernel
```

**Vérification.** `uname -r` donne le noyau en cours, qui figure toujours dans `dpkg -l 'linux-image*'` ou `rpm -q kernel`.

## Nettoyer Docker

**Problème.** `/var/lib/docker` grossit : images remplacées, conteneurs arrêtés, cache de construction, logs des conteneurs.

**Solution.** Mesurez par catégorie :

```bash theme={null}
docker system df
```

Puis nettoyez ce qui n'est plus utilisé :

```bash theme={null}
# Conteneurs arrêtés, réseaux inutilisés, images orphelines, cache de build
docker system prune

# En plus : toutes les images qu'aucun conteneur n'utilise
docker system prune -a
```

> [!WARNING]
>
> N'ajoutez pas `--volumes` sans avoir vérifié la liste avec `docker volume ls`. Un volume contient souvent les données d'une base. Un volume supprimé ne se récupère pas, sauf depuis un snapshot ou une sauvegarde.

Les logs des conteneurs sont l'autre source fréquente. Le pilote par défaut, `json-file`, ne fait aucune rotation. Repérez les plus gros :

```bash theme={null}
sudo sh -c 'du -h /var/lib/docker/containers/*/*-json.log' | sort -h | tail -n 5
```

Activez la rotation dans `/etc/docker/daemon.json` (fusionnez avec le contenu existant si le fichier existe) :

```json theme={null}
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}
```

```bash theme={null}
sudo systemctl restart docker
```

La documentation Docker le précise : le réglage ne s'applique qu'aux conteneurs créés ensuite. Recréez les conteneurs existants (`docker compose up -d --force-recreate` pour un projet Compose).

**Vérification.** `docker system df` affiche une colonne `RECLAIMABLE` proche de zéro.

## Purger les binlogs MySQL et MariaDB

**Problème.** `/var/lib/mysql` contient des dizaines de fichiers `binlog.000123` ou `mysql-bin.000123`.

**Solution.** Ne les supprimez jamais avec `rm` : le serveur tient un index de ces fichiers. Passez par SQL :

```sql theme={null}
-- Liste des binlogs et de leur taille
SHOW BINARY LOGS;

-- Supprime ceux de plus de 7 jours
PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY;
```

Avec un réplica, vérifiez d'abord sur lui le fichier en cours de lecture (`SHOW REPLICA STATUS\G`) : un réplica arrêté ou en retard a encore besoin des binlogs qu'il n'a pas lus.

Pour une expiration automatique, la variable dépend du serveur :

| Serveur | Variable | Valeur par défaut |
| - | - | - |
| MySQL 8.0 et 8.4 | `binlog_expire_logs_seconds` | 2592000 (30 jours) |
| MariaDB 10.6 et suivantes | `binlog_expire_logs_seconds` ou son alias `expire_logs_days` | 0 (pas d'expiration) |
| MariaDB 10.5 et antérieures | `expire_logs_days` | 0 (pas d'expiration) |

`expire_logs_days` a été retirée de MySQL en 8.2 : sur MySQL 8.4, seule `binlog_expire_logs_seconds` existe.

Appliquez la valeur à chaud, puis rendez-la permanente :

```sql theme={null}
SET GLOBAL binlog_expire_logs_seconds = 604800;
```

```bash theme={null}
# Debian, Ubuntu : /etc/mysql/conf.d/ est lu par MySQL et MariaDB
# AlmaLinux, Rocky : utilisez /etc/my.cnf.d/binlog.cnf
sudo tee /etc/mysql/conf.d/binlog.cnf >/dev/null <<'EOF'
[mysqld]
# 7 jours
binlog_expire_logs_seconds = 604800
EOF
```

**Vérification.** `SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';` renvoie `604800`, et `SHOW BINARY LOGS;` ne remonte pas au-delà de sept jours.

## La réserve root d'ext4

**Problème.** `df` affiche 100 % pour vos applications, alors que root peut encore écrire. C'est voulu.

**Explication.** ext4 réserve par défaut 5 % des blocs aux processus privilégiés. La page de manuel `tune2fs` donne la raison : limiter la fragmentation et laisser les démons système fonctionner quand les utilisateurs ne peuvent plus écrire. C'est cette réserve qui vous permet encore de vous connecter et de nettoyer.

```bash theme={null}
# Partition de /
findmnt -n -o SOURCE,FSTYPE /

# Blocs réservés (remplacez /dev/vda1 par la valeur ci-dessus)
sudo tune2fs -l /dev/vda1 | grep -i 'reserved block count'
```

Sur un grand disque de données, vous pouvez la réduire. Sur `/`, ne le faites que pour sortir d'une urgence, puis remettez la valeur :

```bash theme={null}
# Réserve à 1 %, applicable à chaud
sudo tune2fs -m 1 /dev/vda1

# Une fois l'espace libéré : retour à 5 %
sudo tune2fs -m 5 /dev/vda1
```

> [!NOTE]
>
> La réserve ne concerne qu'ext2, ext3 et ext4. Sur XFS, `tune2fs` ne s'applique pas : `findmnt` vous indique le type.

## Si le disque est trop petit

Une fois le ménage fait, si `/` repasse au-dessus de 85 % en quelques semaines, votre usage a simplement grandi. Choisissez une [offre VPS](https://help.onetsolutions.net/fr/vps/offers) avec plus de stockage, puis [étendez la partition](https://help.onetsolutions.net/fr/tutorials/how-to-extend-a-partition) pour profiter du nouvel espace.

## Si le VPS ne répond plus

| Situation | Action |
| - | - |
| SSH ne répond plus, ou la connexion échoue | Ouvrez la [console KVM](https://help.onetsolutions.net/fr/vps/kvm-console) et connectez-vous en root |
| Le VPS ne démarre plus | Démarrez en [mode rescue](https://help.onetsolutions.net/fr/vps/rescue-mode), montez la partition et libérez de l'espace : notre [guide du mode rescue](https://blog.onetsolutions.net/fr/mode-rescue-vps-reparer-serveur-qui-ne-demarre-plus.md) détaille la marche à suivre |
| Un nettoyage a supprimé quelque chose d'utile | Restaurez le [snapshot](https://help.onetsolutions.net/fr/vps/snapshot) pris avant |

## Prévenir : une alerte sur seuil

Le disque plein se voit venir. Un script de quelques lignes vous prévient avant, pour l'espace comme pour les inodes :

```bash theme={null}
sudo tee /usr/local/bin/alerte-disque >/dev/null <<'EOF'
#!/bin/sh
# Alerte quand un système de fichiers dépasse le seuil (espace ou inodes)
SEUIL=85
DEST=admin@example.com

RAPPORT=$(
  for OPT in -P -iP; do
    df $OPT -x tmpfs -x devtmpfs -x overlay | awk -v s="$SEUIL" -v o="$OPT" '
      NR > 1 { sub("%", "", $5); if ($5 + 0 >= s) print $6, $5 "%", (o == "-iP" ? "inodes" : "espace") }'
  done
)

[ -n "$RAPPORT" ] && printf '%s\n' "$RAPPORT" | mail -s "Disque presque plein sur $(hostname)" "$DEST"
exit 0
EOF
sudo chmod 755 /usr/local/bin/alerte-disque

# Toutes les 15 minutes
echo '*/15 * * * * root /usr/local/bin/alerte-disque' | sudo tee /etc/cron.d/alerte-disque >/dev/null
```

L'envoi passe par la commande `mail` (paquet `bsd-mailx` sur Debian et Ubuntu, `s-nail` sur AlmaLinux et Rocky) et un serveur de messagerie local. Notre guide [SPF, DKIM, DMARC et reverse DNS](https://blog.onetsolutions.net/fr/spf-dkim-dmarc-reverse-dns-serveur-mail-vps.md) couvre la délivrabilité.

**Vérification.** Lancez le script avec un seuil à 1 pour recevoir un message de test :

```bash theme={null}
sudo sed 's/^SEUIL=85/SEUIL=1/' /usr/local/bin/alerte-disque | sudo sh
```

Ajoutez-y une règle logrotate pour chaque application qui écrit ses propres logs, et un plafond pour le journal : ce sont les deux sources qui reviennent le plus vite.

## Pièges courants

**`rm` sur un log ouvert.** L'espace n'est pas rendu tant que le processus tourne. Utilisez `truncate -s 0`, ou redémarrez le service après coup.

**Supprimer les fichiers du journal à la main.** `journalctl --vacuum-size` ne supprime que les archives, jamais le fichier en cours d'écriture. Laissez-lui le travail plutôt que `rm` dans `/var/log/journal`.

**Des fichiers cachés sous un point de montage.** Des fichiers écrits dans un répertoire avant qu'un disque y soit monté occupent `/` mais restent invisibles pour `du`. Montez `/` ailleurs pour les voir :

```bash theme={null}
sudo mkdir -p /mnt/racine
sudo mount --bind / /mnt/racine
sudo du -xh -d 2 /mnt/racine 2>/dev/null | sort -h | tail -n 15
sudo umount /mnt/racine
```

**Des inodes épuisés, pas l'espace.** `df -h` affiche de la place libre et l'erreur persiste : regardez `df -i`.

**`docker system prune --volumes` en production.** Il supprime les volumes non utilisés à cet instant, y compris celui d'une base dont le conteneur est arrêté.

**Les binlogs supprimés à la main.** Le serveur garde leur liste dans un fichier d'index, que `rm` ne met pas à jour. Passez toujours par `PURGE BINARY LOGS`.

## Pour aller plus loin

* [Snapshots](https://help.onetsolutions.net/fr/vps/snapshot) : un point de retour avant chaque nettoyage risqué
* [Sauvegardes](https://help.onetsolutions.net/fr/vps/backup) : la protection de fond de vos données
* [Étendre une partition](https://help.onetsolutions.net/fr/tutorials/how-to-extend-a-partition) après un passage à une offre plus grande
* [Console KVM](https://help.onetsolutions.net/fr/vps/kvm-console) et [mode rescue](https://help.onetsolutions.net/fr/vps/rescue-mode) : reprendre la main sur un VPS qui ne répond plus
* [VPS qui ne démarre plus : le mode rescue](https://blog.onetsolutions.net/fr/mode-rescue-vps-reparer-serveur-qui-ne-demarre-plus.md), pas à pas
* [Mises à jour de sécurité automatiques](https://blog.onetsolutions.net/fr/mises-a-jour-securite-automatiques-vps-linux.md) : elles aussi ont besoin d'espace libre pour s'installer

Une question sur un serveur hébergé chez nous ? [Notre équipe est disponible](https://help.onetsolutions.net/fr/console/support) depuis votre espace client.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.