'docker system prune -a' est-il sans risque ?

Il supprime les conteneurs arrêtés, les réseaux inutilisés, le cache de build et toutes les images qu'aucun conteneur en marche n'utilise. Vos données restent tant que vous n'ajoutez pas --volumes. Avec cette option, les volumes inutilisés partent aussi — et le volume d'un conteneur de base de données arrêté compte comme inutilisé. Évitez cette option si vous n'êtes pas sûr.

J'ai supprimé un gros log mais df affiche toujours le disque plein. Pourquoi ?

Un processus en cours garde le fichier ouvert, donc le noyau conserve l'espace. Trouvez-le avec 'lsof +L1' et redémarrez ce service. La prochaine fois, videz un log actif avec 'truncate -s 0 fichier' au lieu de le supprimer.

Combien d'espace libre garder ?

Au moins 10–15 %. Les bases de données, les mises à jour de paquets et les pulls Docker ont besoin d'espace temporaire, et un disque à 100 % peut corrompre une base en pleine écriture.

Puis-je agrandir le disque sans réinstaller ?

Oui. Passer à une offre supérieure agrandit le disque sur place et conserve vos données : Nano a 15 Go, Micro 25 Go, Small 35 Go, Medium 45 Go. Le serveur redémarre une fois.

Qu'est-ce qui remplit d'habitude un petit VPS ?

D'après notre expérience : les images et le cache de build Docker, les journaux systemd, les logs d'applications que personne ne fait tourner, et des dumps de base ou archives oubliés dans /root.

Libérer de l'espace disque sur un VPS sans rien casser

Disque plein sur votre VPS ? Trouvez ce qui prend la place avec du et ncdu, puis videz le cache apt, les journaux, les restes de Docker et les logs sans perdre de données.

« No space left on device » n'arrive jamais au bon moment. La base de données refuse les écritures, apt ne peut pas terminer une mise à jour et Docker refuse de récupérer l'image dont vous avez besoin tout de suite. La bonne nouvelle : sur un petit VPS, le coupable est presque toujours l'un de cinq suspects, et vous le trouvez en deux minutes.

1. C'est grave à quel point ?

df -h /
df -i /

La première ligne montre l'espace utilisé. La seconde montre les inodes : s'ils atteignent 100 % alors que l'espace semble suffisant, vous avez des millions de petits fichiers (sessions, file d'attente mail, répertoire de cache). Autre problème, même symptôme.

2. Trouver ce qui est gros

Parcourez l'arborescence depuis la racine et triez par taille :

du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15

-x reste sur un seul système de fichiers, sans s'égarer dans /proc. Descendez ensuite dans le plus gros répertoire. Pour explorer de façon interactive, ncdu est bien plus agréable :

apt install -y ncdu
ncdu -x /

Flèches pour naviguer, d pour supprimer. Prudence avec ce dernier.

3. Les gains rapides

C'est sans danger sur n'importe quel serveur Ubuntu ou Debian :

apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M

apt autoremove supprime aussi les anciens noyaux. Le journal systemd est celui qui surprend le plus : sans limite, il peut grossir jusqu'à plusieurs gigaoctets. Pour le plafonner durablement, mettez SystemMaxUse=200M dans /etc/systemd/journald.conf et lancez systemctl restart systemd-journald.

4. Les restes de Docker

Si vous utilisez Docker, regardez ici en premier. Les vieilles images et le cache de build s'accumulent à chaque déploiement :

docker system df
docker image prune -a
docker builder prune

docker image prune -a supprime les images qu'aucun conteneur en marche n'utilise. C'est généralement ce qu'on veut, mais le prochain déploiement les retéléchargera.

Le dangereux, c'est docker system prune -a --volumes. Les volumes contiennent vos données, et un volume d'un conteneur arrêté compte comme inutilisé. C'est comme ça qu'on perd des bases de données. Ne le collez pas depuis une réponse de forum.

Les logs des conteneurs sont l'autre dévoreur caché. Plafonnez-les dans /etc/docker/daemon.json :

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

Redémarrez Docker ensuite. La limite ne s'applique qu'aux conteneurs créés après, donc recréez les plus bavards avec docker compose up -d --force-recreate.

5. Logs et fichiers oubliés

Trouvez les gros fichiers partout sur le disque :

find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null

Les trouvailles habituelles : un backup.tar.gz d'il y a six mois dans /root, un dump de base que quelqu'un voulait télécharger, un log d'application jamais tourné.

Pour un log dans lequel un service écrit encore, pas de rm — videz-le :

truncate -s 0 /var/log/myapp/app.log

Si vous l'avez déjà supprimé et que l'espace n'est pas revenu, un processus le garde ouvert :

lsof +L1

Redémarrez le service indiqué et l'espace revient.

Quand le ménage ne suffit pas

Parfois, les données sont simplement réelles : une base qui grossit, des fichiers envoyés par les utilisateurs, un fichier de modèle. La solution honnête, c'est alors plus de disque. Changer d'offre agrandit le disque sur place et conserve tout : Nano a 15 Go, Micro 25 Go, Small 35 Go, Medium 45 Go. Le serveur redémarre une fois. Les détails sont dans la documentation des offres.

Autre chose occupe discrètement de la place : un fichier de swap. Si vous avez suivi notre guide du swap, ces 1–2 Go sont là exprès. Et si Docker est le principal consommateur, l'installation de Docker et le déploiement d'une stack Compose montrent comment garder les images sous contrôle.

L'habitude qui évite tout ça : plafonner le journal et les logs Docker dès le premier jour. Deux lignes de configuration, et le « disque plein » n'arrive presque plus.