Disque Linux plein : détecter la cause avant de supprimer dans l'urgence

L'app renvoie 500. SSH fonctionne encore. df -h affiche 100 % sur /. Le reflexe : rm -rf /var/log/*.log. Ça libère 200 Mo — puis le disque regorge en deux heures parce que personne n'a vu que MySQL binlog ou Docker logs avalait 40 Go.

Un disque plein est symptôme, pas diagnostic.

Lecture rapide df/du

df -hT : filesystem type, inodes (df -i). du -xh / --max-depth=1 sur mount point.

Comparez df vs du total — écart = deleted open files ou mount caché.

Coupables fréquents

Chronologie : find /var -mtime -1 -size +100M.

Deleted but open

lsof +L1 | grep deleted — classique après rotate raté ou gros log supprimé sans HUP.

Fix : reload app, restart php-fpm/mysql, pas seulement rm.

Actions d'urgence ordonnées

1. Identifier top 3 dossiers.
2. Vacuum journald si > 500 Mo.
3. Truncate log connu (copytruncate) vs delete.
4. Docker prune après list volumes.
5. Étendre volume cloud si possible avant chirurgie.

Prévention durable

Monitoring inode + espace. Logrotate testé. SystemMaxUse= journald. Docker --log-opt max-size=10m. Alert runbook lié au bon mount.

Runbook 15 minutes

Minute 0–3 : df -hT + df -i + du -xh / --max-depth=1.

Minute 3–6 : journalctl --disk-usage, docker system df si applicable.

Minute 6–9 : lsof +L1 | head si df/du gap.

Minute 9–12 : action ciblée (vacuum, truncate log roté, prune docker volumes listés).

Minute 12–15 : df verify + alerte monitoring ack + ticket cause racine.

Interdit : rm -rf sans top 3 dirs identifiés. Obligatoire : note post-mortem si >80% prod impact.

Post-mortem type

Timeline : alert 80% ignorée → 95% → 100% → outage. Cause racine : log application debug activé vendredi sans rotation. Action : log level prod + alert 85% + runbook.

Capacité : prevision croissance logs Mo/jour × retention.

Cloud autoscale disk si disponible — script grow filesystem post-resize.

Snapshots cloud auto daily sans lifecycle : accumulation snapshots = disque parent plein indirectement — revue policy snapshots.

Mail queue postfix/exim bloquée disque plein : backlog énorme au recover — surveillez queue length metric.

Croissance prévisible

Logs accès ×10 lors promo : pre-provision rotation hourly temporaire ou disk upgrade avant campagne.

MySQL binlog expiration : expire_logs_days ou max_binlog_size — binlog oubli = disque plein garanti sous write-heavy.

ZFS/btrfs snapshots comptent espace — ne snapshottez pas un disque déjà plein en boucle.

Synthèse opérationnelle

Disque plein sur Linux production est presque toujours prévisible avec alertes 80/90 %, rotation logs testée, et connaissance des consommateurs (journald, Docker, binlog, backups locaux). En urgence : diagnostiquer avec df, du, lsof avant rm.

Cloud : étendre volume plus sûr que purge aveugle si croissance legit. Post-mortem obligatoire si impact client — souvent debug log oublié activé.

Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.

Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.

Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.

Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.

Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.

Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.

Post-mortem

Debug log vendredi sans rotation. K8s ephemeral storage tue pods avant node full.

Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.

Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.

Décider et avancer sans angle mort

1. Runbook 15 minutes — df -hT, df -i, du top-level, journalctl --disk-usage, docker system df.
2. Chercher les fichiers supprimés ouverts — lsof +L1 si écart df/du.
3. Action ciblée — vacuum journal, truncate log roté, prune docker volumes listés ; jamais rm -rf sans top 3 dirs.
4. Alerter sur la dérivée — croissance Go/jour, pas seulement seuil 90 %.
5. Post-mortem si impact prod — cause racine documentée la même semaine.

Surveillez disque et inode sur VPS via le comparateur et l'annuaire.

Questions fréquentes

df dit 100 % mais du ne trouve rien ?

Fichiers supprimés encore ouverts par un process (deleted but open). lsof +L1 ou restart du service concerné.

Que purger en premier en urgence ?

journalctl --vacuum, logs rotés anciens, /tmp — jamais /var/lib sans identifier (DB, docker).

Docker remplit souvent où ?

/var/lib/docker/overlay2, logs json-file non limités, volumes orphelins.

Comment prévenir ?

Alertes à 80/90 %, logrotate, limite journald, docker log opts max-size.

Prochain 100 % disque : lancez du et lsof +L1 avant tout rm — votre futur vous remerciera.