Alfresco Community : nettoyer le contentstore.deleted sans supprimer l’utile

Pourquoi ce sujet revient souvent en exploitation

Dans beaucoup d environnements Alfresco Community, l espace disque finit par devenir un sujet de tension avant même qu une vraie panne n apparaisse. Les symptômes sont souvent les mêmes : le serveur grossit plus vite que prévu, le dossier contentstore prend plusieurs dizaines ou centaines de Go, le dossier contentstore.deleted n est jamais examine, et l équipe hesite a supprimer quoi que ce soit par peur de casser la GED.

Cette hesitation est saine. Sur Alfresco Community, une purge mal comprise peut transformer un simple sujet de capacité en incident de production. A l inverse, ne rien faire laisse s accumuler des fichiers orphelins, allonge les sauvegardes et complique les restaurations. L enjeu n est donc pas de supprimer agressivement, mais de comprendre ce qui releve du cycle de vie normal d Alfresco et ce qui merite une action controlee.

Chez Rainbow Integration, nous voyons ce sujet surtout après une phase de croissance documentaire, une reprise d historique ou une sequence d essais en environnement Docker. Il est aussi fréquent après des suppressions massives de dossiers ou des reprises de sauvegarde réalisées sans vérification métier. Si votre équipe administre déjà la plateforme, vous pouvez rapprocher ce travail de votre politique de sauvegarde et restauration Alfresco Community pour éviter les faux gains de place qui degradent en réalité votre capacité de retour arrière.

Ce que contient vraiment le contentstore.deleted

Un point important est souvent mal interprete : la présence de fichiers dans contentstore.deleted ne signifie pas automatiquement qu Alfresco est en erreur. Dans le fonctionnement normal, Alfresco stocké les binaires dans contentstore, conserve les références et les métadonnées en base, puis deplace certains contenus supprimes vers un espace de suppression avant leur nettoyage definitif. Autrement dit, le disque raconte une partie de l histoire, mais jamais toute l histoire.

Si vous regardez uniquement la taille du système de fichiers, vous risquez de conclure trop vite que rien n est purge. En pratique, il faut distinguer au moins quatre cas :

• des contenus encore legitimes et références par la base ;
• des contenus supprimes mais encore retenus par le cycle de nettoyage ;
• des fichiers orphelins qui n ont plus de référence utile ;
• des incohérences créées par une manipulation manuelle, une restauration partielle ou un incident d exploitation.

C est cette distinction qui permet d agir sans risque. Une purge manuelle à la hache dans le filesystem est rarement une bonne pratique. En revanche, un diagnostic methodique permet de savoir si vous avez un problème de rétention normale, de job de nettoyage non exécuté, ou de decalage plus profond entre base et système de fichiers.

Les signaux qui doivent déclencher un diagnostic

Vous n avez pas besoin d attendre une saturation totale du disque pour ouvrir le sujet. Quelques signaux faibles suffisent :

• la volumétrie du serveur augmente plus vite que la volumétrie métier attendue ;
• les sauvegardes deviennent plus longues alors que le nombre d utilisateurs reste stable ;
• des campagnes de suppression n ont produit aucun gain mesurable ;
• des environnements de test ou de reprise ont ete recrees plusieurs fois ;
• le nettoyage des contenus supprimes n est documente nulle part dans l exploitation.

Dans ces situations, l objectif n est pas uniquement de faire de la place. Il faut aussi reduire le risque de desalignement avec la base, protéger la future restauration et garder une lecture claire de ce qui est encore actif. C est exactement la même logique que pour un diagnostic d indexation : on commence par qualifier le symptôme avant d engager une action irreversible. Si vous avez déjà rencontre des ecarts entre documents visibles et résultats de recherche, l article sur le diagnostic Solr et la réindexation Alfresco montre bien pourquoi une correction technique doit être precedee d un cadrage minimal.

méthode de purge propre en environnement Community

La bonne approche consiste a traiter le nettoyage comme une opération d exploitation controlee, pas comme une suppression opportuniste. Une méthode simple et robuste peut se decouper en cinq étapes.

1. Qualifier le contexte

Commencez par noter la version d Alfresco Community, le mode d hébergement, la volumétrie approximative du repository, la fenêtre de maintenance disponible et la présence ou non d un environnement de preproduction. Ce cadrage évite d appliquer la même recette à un petit serveur mono instance et à une plateforme plus critique.

2. Vérifier les mécanismes natifs avant toute suppression

Avant de toucher au disque, confirmez que les jobs lies au nettoyage ont bien eu l occasion de s exécuter. Si le comportement semble anormal, regardez les journaux, les erreurs applicatives et le calendrier de maintenance. Sur des environnements montes rapidement avec Alfresco Community via Docker Compose, il n est pas rare de retrouver des hypotheses d exploitation insuffisamment formalisees : volumes persistants mal suivis, nettoyage jamais observe, ou redémarrages qui brouillent la lecture de l historique.

3. Mesurer avant et après

Prenez un point zero : taille de contentstore, taille de contentstore.deleted, date des dernières grosses suppressions, et dernier backup exploitable. Sans cette mesure, impossible de distinguer un vrai gain d une simple impression. Ce point est fondamental pour ne pas transformer l exploitation en suite d actions non tracables.

4. Sauvegarder avant opération irreversible

Une purge propre suppose toujours un retour arrière possible. Si la sauvegarde applicative et la sauvegarde du contenu ne sont pas cohérentes, la place gagnee peut couter très cher lors d une restauration. Ce sujet est souvent sous estime alors qu il conditionne la sécurité de toute intervention.

5. Purger dans une fenêtre controlee puis vérifier

Après vérification du mécanisme natif, la purge doit être suivie d un contrôle simple : ouverture de documents recents, consultation de contenus supprimes si nécessaire, vérification des journaux et mesure de la volumétrie. L idee n est pas d ajouter de la complexité, mais de confirmer que la GED reste cohérente pour les utilisateurs et pour l équipe support.

Les erreurs a éviter absolument

La première erreur consiste a supprimer directement des fichiers du contentstore parce qu ils semblent vieux ou nombreux. Ce répertoire est le coeur physique des contenus. Une suppression manuelle a cet endroit peut créer une dette invisible qui ne se revelera qu a l ouverture d un document critique.

La deuxieme erreur consiste a croire qu une baisse du nombre de documents en interface doit se traduire instantanement par une baisse du disque. Alfresco se base sur un cycle de traitement, des références et des mécanismes de nettoyage qui ne se lisent pas comme une simple corbeille utilisateur.

La troisieme erreur consiste a intervenir sans journal d exploitation. Si vous ne notez ni la date, ni la volumétrie avant après, ni la sauvegarde utilisee, vous perdez la capacité d expliquer un incident ulterieur. Pour une PME ou une ETI, c est souvent ce manque de traçabilité qui transforme un sujet technique banal en arbitrage couteux.

Quand demander un accompagnement plutôt qu une purge interne

Une équipe interne peut gérer ce sujet seule si elle maîtrise l architecture Alfresco, la politique de sauvegarde et les vérifications post intervention. En revanche, il est plus prudent de se faire accompagner lorsque :

• le serveur approche d un seuil critique de capacité ;
• vous avez eu des restaurations partielles ou des incidents recents ;
• la plateforme supporte des documents qualité, RH ou contractuels sensibles ;
• personne ne sait décrire le cycle de purge reel en production ;
• vous soupconnez déjà un ecart entre base, index et système de fichiers.

Dans ce cas, l enjeu n est pas seulement de supprimer des fichiers. Il s agit de reconstituer une règle d exploitation fiable, documentee et repetable. Rainbow Integration intervient souvent à ce stade pour cadrer le diagnostic, separer les fichiers simplement retenus des contenus réellement orphelins, puis remettre en place un mode operatoire tenable dans le temps.

Ce qu il faut retenir

Sur Alfresco Community, nettoyer contentstore.deleted n est ni un sujet cosmetique, ni une opération a improviser. C est un travail d exploitation qui demande une lecture croisee du disque, de la base, des sauvegardes et du comportement reel de la plateforme. Bien mene, il reduit la pression de capacité et fiabilise les futures restaurations. Mal mene, il peut introduire une perte documentaire silencieuse.

Si vous constatez une croissance anormale de votre stockage ou un doute sur les contenus orphelins, mieux vaut cadrer le sujet tot plutôt que d attendre la saturation. C est souvent à ce moment-la qu une intervention ciblee permet d éviter une crise, tout en remettant votre exploitation Alfresco sur des bases plus propres.

Votre stratégie de purge protège-t-elle vraiment les contenus utiles ? Faire contrôler votre stockage Alfresco.