Comment supprimer l'historique des messages et les médias anciens dans Matrix Synapse

Scénario d'exemple (à titre indicatif uniquement) : Northstar Community, une association fictive, utilise un serveur Matrix Synapse. Sa base de données et sa bibliothèque multimédia s'agrandissent, et l'administrateur souhaite supprimer l'historique des salles et les fichiers multimédias obsolètes sans effacer accidentellement les discussions en cours ni les images de profil. Cet exemple ne correspond pas à un déploiement réel ni à un résultat de test.

L'essentiel est de traiter l'historique des messages et les médias comme deux tâches de nettoyage distinctes. Synapse propose une API de purge de l'historique des salles et des outils de nettoyage des médias séparés ; un paramètre de conservation des médias permet également de supprimer des fichiers tout en conservant les événements Matrix qui y font référence. Commencez par déterminer les éléments qui doivent rester disponibles, puis sauvegardez la base de données et le stockage des médias, choisissez la méthode appropriée et vérifiez ensuite les deux zones de stockage.

Déterminez ce que signifie « ancien » pour votre serveur

Avant de modifier la configuration ou d'utiliser une fonction destructive, définissez une règle de conservation. Dans l'exemple de Northstar, supposons que le conseil d'administration approuve la conservation de l'historique des salles pendant 180 jours, des téléchargements locaux selon une politique similaire, et considère les médias distants comme un cache pouvant être récupéré ultérieurement si nécessaire. Une autre organisation pourrait exiger une conservation de plusieurs années pour des raisons légales, opérationnelles ou liées à la communauté. Ces durées sont données à titre indicatif et ne constituent pas des recommandations universelles.

Séparez les données en deux catégories :

• Événements de la salle : messages et autres événements stockés dans la base de données de Synapse. La suppression des événements modifie la limite de l’historique consultable par les utilisateurs dans la salle.
• Médias : fichiers téléchargés, vignettes et copies en cache de fichiers provenant d’autres serveurs d’hébergement. Ces éléments sont stockés dans le répertoire multimédia ou dans un répertoire externe configuré.

La documentation officielle de Synapse décrit les politiques de conservation des événements et le nettoyage des médias séparément. La purge de l'historique d'une salle ne garantit pas à elle seule le nettoyage du stockage multimédia, et la suppression d'un fichier multimédia n'efface pas l'événement associé. Commencez par noter la taille de la base de données, la taille du stockage multimédia, les salles concernées et la date limite prévue. Consultez le manuel de configuration de Synapse .

Sauvegardez avant de purger

Effectuez une sauvegarde de la base de données en suivant la procédure recommandée pour votre moteur de base de données, et sauvegardez également le référentiel multimédia ou le stockage multimédia externe. Une sauvegarde de la base de données seule ne préserve pas les fichiers téléchargés ; une sauvegarde multimédia seule ne restaure pas les événements de salle. Assurez-vous que les sauvegardes sont lisibles et que vous savez comment les restaurer avant de poursuivre. Si Synapse s'exécute dans des conteneurs ou utilise des nœuds de calcul distincts, intégrez la configuration et les volumes de stockage correspondants à votre plan de maintenance.

Pour le serveur hypothétique de Northstar, l'administrateur enregistre la taille de la base de données et du stockage multimédia et vérifie l'existence d'un point de restauration récent avant d'intervenir sur les espaces partagés. Cette précaution est essentielle car un « nettoyage » n'est réussi que s'il supprime les données souhaitées tout en laissant récupérables les données nécessaires.

Choisissez un programme de rétention pour un nettoyage continu

Pour que Synapse continue d'appliquer une politique, configurez séparément la conservation des événements et des médias dans la configuration du serveur d'accueil. Par exemple, un administrateur peut adapter cet exemple pour un serveur dont la politique approuvée est de 180 jours pour l'historique des salles et les médias locaux, avec un cache de 30 jours pour les médias distants :

retention:
  enabled: true
  default_policy:
    max_lifetime: 180d

media_retention:
  local_media_lifetime: 180d
  remote_media_lifetime: 30d

Il s'agit d'une configuration illustrative, et non d'une politique applicable à tous les serveurs. Synapse indique que la conservation des événements est désactivée par défaut. Cela default_policyconcerne les salles sans m.room.retentionévénement d'état ; les administrateurs de salle peuvent définir des politiques de salle, tandis que les administrateurs de serveur peuvent limiter la durée de vie des politiques à l'aide des paramètres de durée de vie autorisés. Si vous avez besoin d'une limite supérieure cohérente, consultez ces paramètres et les politiques de salle déjà en vigueur plutôt que de supposer que la configuration par défaut s'applique à toutes les salles.

La durée de vie des médias est calculée à partir du temps écoulé depuis leur dernier accès. Si un élément n'a jamais été consulté, Synapse utilise sa date de création. Ce paramètre s'applique aux fichiers originaux et aux miniatures ; une durée de vie non définie ou nulle n'entraîne pas la suppression de la catégorie de médias correspondante. Un élément mis en cache à distance peut être demandé à nouveau à son origine après avoir été supprimé. Les médias mis en quarantaine et les médias protégés localement font exception et ne sont pas concernés par ces paramètres de conservation. Le nettoyage des médias s'effectue sur le processus ou le nœud de calcul Synapse enable_media_repoactivé. Consultez la documentation relative à la conservation actuelle et à la fonction `media_retention` , puis appliquez la configuration en suivant la procédure de redémarrage ou de déploiement habituelle de votre installation.

Avant d'adopter l'exemple, comparez son comportement à vos besoins. Si un message de salon doit rester lisible avec sa pièce jointe pendant 180 jours, ne choisissez pas une durée de vie des médias plus courte, sauf si vous acceptez que le message puisse survivre au fichier disponible localement. Vérifiez si vos médias sont stockés dans Synapse ou dans un dépôt externe ; l'API de suppression des médias locaux de Synapse ne supprime pas les médias stockés dans un dépôt externe.

Supprimer les événements de salle plus anciens à la demande

Pour un nettoyage ponctuel, utilisez l'API d'administration de l'historique de purge de Synapse. Cette opération requiert un jeton d'accès d'administrateur serveur ; être administrateur d'une salle individuelle ne confère pas les mêmes autorisations. Synapse recommande de masquer l'API d'administration et d'effectuer ces requêtes depuis le serveur ou un hôte d'administration de confiance. Ne collez jamais un jeton d'accès actif dans l'historique, les tickets ou les journaux d'un shell partagé.

La requête doit spécifier une limite de traitement à l'aide d'un identifiant d'événement ou d'un horodatage Unix en millisecondes. L'exemple de ligne de commande suivant est fourni à titre d'illustration. Remplacez le serveur d'accueil, l'identifiant de la salle, la variable « token » et la limite de traitement par les valeurs que vous avez examinées. Cet exemple demande également la suppression des événements de messages de l'utilisateur local.

export SYNAPSE_ADMIN_TOKEN='replace-with-a-server-admin-token'
PURGE_CUTOFF_MS=1760000000000  # replace with the approved UTC cutoff

curl --fail-with-body -X POST \
  -H "Authorization: Bearer $SYNAPSE_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  --data "{\"purge_up_to_ts\": $PURGE_CUTOFF_MS, \"delete_local_events\": true}" \
  "https://matrix.example.org/_synapse/admin/v1/purge_history/!room:example.org"

Sans cette delete_local_events: trueoption, Synapse conserve par défaut les événements envoyés par les utilisateurs locaux ; les événements envoyés à distance peuvent être supprimés. L’état des salons, comme les membres et l’état des sujets, est conservé. Synapse conserve également au moins un message dans chaque salon. L’opération peut prendre plusieurs minutes, voire plus, et les utilisateurs ne peuvent pas naviguer dans l’historique de la purge pendant son exécution. L’API renvoie immédiatement un ID de purge ; interrogez-la /_synapse/admin/v1/purge_history_status/<purge_id>jusqu’à ce que le statut soit « OK » completeou examinez l’erreur si elle est « OK » failed. Consultez la documentation de l’API « Historique de purge » avant de définir une durée limite. En particulier, vérifiez si la suppression des événements locaux est appropriée pour vos salons.

Nettoyer séparément les médias locaux et le cache distant

Pour un nettoyage régulier, utilisez media_retentiondes durées de vie adaptées à la disponibilité promise aux utilisateurs. Pour un nettoyage ponctuel, Synapse propose différents points de terminaison :

• Médias locaux : POST /_synapse/admin/v1/media/delete?before_ts=<timestamp_ms> supprime les médias locaux éligibles en fonction de leur date de dernière utilisation. L’API accepte également un seuil de taille. Les médias de profil et d’avatar de salle sont conservés par défaut ; ne désactivez cette protection qu’après avoir soigneusement examiné les conséquences.
• Mise en cache des médias distants : POST /_synapse/admin/v1/purge_media_cache?before_ts=<timestamp_ms> supprime les médias distants mis en cache dont le dernier accès remonte à une période antérieure à la date limite. Si un utilisateur demande ultérieurement un fichier distant supprimé, Synapse peut le récupérer auprès du serveur d'origine.

Les deux points de terminaison utilisent un horodatage Unix positif en millisecondes, et la suppression des médias est basée sur la dernière consultation, et non sur la date de création ou de chargement. L'API de suppression locale supprime le fichier et ses miniatures du stockage Synapse, y compris les copies mises en cache localement pour les fichiers distants ; elle ne supprime pas les fichiers d'un dépôt externe. La réponse indique le nombre d'éléments supprimés. Consultez la documentation de l' API d'administration des médias Synapse pour connaître les paramètres et les détails des points de terminaison avant d'effectuer une requête.

Dans l'exemple de Northstar, un administrateur commencerait par vérifier la conformité du seuil avec la politique approuvée et s'assurerait que les identifiants ou les nombres renvoyés par le point de terminaison correspondent aux attentes. Si le cache distant est la seule source de croissance, la purge des chargements locaux serait une opération inappropriée. Si les chargements locaux doivent rester disponibles, il convient d'opter pour une durée de vie locale plus longue ou d'éviter le point de terminaison de purge des médias locaux.

Mesurez le résultat et changez de cap si nécessaire.

Après chaque opération, vérifiez que la purge s'est déroulée correctement, consultez le nombre de réponses de l'API, assurez-vous que les salles représentatives affichent bien l'historique attendu et comparez séparément l'utilisation de la base de données et du stockage multimédia. Une réduction du nombre de lignes dans la base de données peut ne pas se traduire immédiatement par une réduction équivalente de l'espace disque utilisé par le système d'exploitation ; la récupération d'espace dépend du moteur de base de données et de ses procédures de maintenance. Suivez les recommandations du fournisseur de la base de données plutôt que de supprimer manuellement les fichiers.

Si la base de données diminue mais pas le stockage des médias, vérifiez la conservation des médias, le traitement des médias enable_media_repo(en cas de mise en quarantaine ou de protection) et si les fichiers sont stockés en externe. Si l'utilisation des médias diminue mais que d'anciens messages persistent, cela est normal si seuls les médias ont été purgés. Si des événements persistent de manière inattendue, vérifiez si la conservation est activée, si la salle possède son propre état de conservation, si des événements locaux ont été intentionnellement conservés et si la purge est terminée.

Pour Northstar, le critère de réussite ne se limite pas à la réduction de la taille du disque. Il s'agit de vérifier que la limite de l'historique approuvé est visible, que les messages et pièces jointes requis fonctionnent toujours, que la catégorie de médias prévue a été nettoyée et que les deux sauvegardes restent disponibles. Si ces vérifications échouent, interrompez les purges et examinez la politique de la salle, la réponse de l'API, la configuration du worker et le système de stockage avant d'étendre le nettoyage.

Limites à garder à l'esprit

Les politiques de conservation ne remplacent pas l'examen juridique ou de conservation des documents de l'organisation. La fédération implique que d'autres serveurs peuvent conserver leurs propres copies d'événements ou de fichiers multimédias, et Synapse ne peut garantir leur suppression de ces serveurs. La purge des fichiers multimédias à distance supprime le cache de ce serveur ; elle ne supprime pas le fichier source sur son serveur d'origine. De même, la suppression d'un événement ou d'un fichier multimédia local dans Synapse ne restaure pas une copie déjà téléchargée par un autre participant.

Utilisez la rétention planifiée pour appliquer une politique reproductible ; utilisez les API d’administration pour un nettoyage ciblé et validé. Conservez ces deux opérations distinctes dans votre historique des modifications, car leurs indicateurs de réussite et leurs effets diffèrent.