Disk quota exceeded : ce message, renvoyé en plein milieu d’un import CSV de cent mille fiches produits sur un hébergement mutualisé, a stoppé net la commande à la fiche numéro 63 421. Aucune indication précise sur ce qui saturait l’espace, juste l’échec brutal d’une écriture. Le site restait accessible en lecture, mais toute tentative d’écriture — y compris les logs WordPress — échouait de la même façon.
Ce type de panne est trompeur parce que le quota affiché par l’hébergeur dans son panneau de contrôle ne correspond pas toujours à ce qu’on imagine : sur cette offre mutualisée, il incluait les sauvegardes automatiques quotidiennes conservées sept jours, en plus des fichiers du site et de la base de données. Un import volumineux, même transitoire, peut donc faire déborder un quota qui semblait large la veille.
Symptôme : où ça casse exactement
La commande d’import s’est arrêtée avec une erreur PHP visible dans les logs d’erreur du serveur : fwrite(): Write of 8192 bytes failed with errno=122 Disk quota exceeded. Ce code d’erreur 122 est spécifique au système de fichiers et signale un dépassement de quota utilisateur, distinct d’un espace disque physiquement plein sur le serveur. Le site restait en ligne, mais toute écriture — cache de transients, logs, nouveaux médias — échouait silencieusement pour les visiteurs, sans message d’erreur visible côté front.
Diagnostic : localiser ce qui consomme l’espace
La première étape a consisté à quantifier l’espace réellement occupé par composant, via une commande combinant du et le répertoire WordPress :
du -sh wp-content/uploads wp-content/cache wp-content/plugins wp-content/themes 2>/dev/null | sort -rh
Le résultat a montré que wp-content/uploads ne représentait que 1,2 Go, très loin du quota de 10 Go. Le vrai coupable était ailleurs : un répertoire de sauvegardes locales généré par une extension de sauvegarde installée par précaution des années plus tôt, jamais purgé, qui conservait chaque archive complète du site sans rotation. Ce répertoire à lui seul pesait 6,8 Go, invisible dans les outils habituels d’analyse de médias.
Correctif : purger, planifier une rotation, relancer
La correction s’est faite en trois temps. D’abord, la suppression des archives obsolètes de plus de trente jours via une commande ciblée. Ensuite, la désactivation de l’extension de sauvegarde locale redondante avec le système de sauvegarde de l’hébergeur déjà en place. Enfin, la vérification que l’import pouvait reprendre sans erreur, en le relançant par lots de dix mille lignes plutôt qu’en une seule commande de cent mille, pour limiter l’impact d’un éventuel nouvel incident.
wp cron event list --path=/home/client/public_html
find wp-content/uploads/backup-archives -mtime +30 -name "*.zip" -delete
wp import run import-fiches-2023-09.xml --authors=create --path=/home/client/public_html
Reprendre un import interrompu sans doublons
Un import CSV interrompu à la fiche 63 421 pose une question pratique : comment reprendre sans recréer les fiches déjà importées ? Notre script d’import personnalisé, basé sur WP_CLI\Utils\iterate_files, s’appuyait sur une colonne d’identifiant externe unique vérifiée via get_page_by_path avant chaque insertion, ce qui a permis de relancer l’import sur l’intégralité du fichier sans provoquer de doublons pour les 63 421 fiches déjà traitées.
Prévention : ce qu’on a changé depuis
- Un contrôle d’espace disque disponible avant chaque import volumineux, via un script qui refuse de démarrer si moins de 20 % du quota est libre.
- Une règle de rotation automatique des archives de sauvegarde locales, limitée aux sept derniers jours quel que soit le plugin utilisé.
- Un import découpé par défaut en lots de dix mille lignes maximum, avec point de reprise enregistré, pour tout fichier dépassant vingt mille entrées.
Un quota affiché large sur un mutualisé ne dit rien de ce qu’il contient déjà. Le vérifier avant un import volumineux prend cinq minutes ; le découvrir en pleine exécution en coûte beaucoup plus.
Ce qu’il faut retenir
Sur un hébergement mutualisé, le quota disque est rarement un chiffre isolé : il englobe souvent des sauvegardes, des logs et des caches qui échappent aux outils habituels de suivi des médias. Avant tout import volumineux, un contrôle d’espace disponible et une purge des répertoires oubliés évitent l’arrêt brutal en plein traitement, bien plus coûteux à diagnostiquer après coup qu’à anticiper avant.
