Accueil
» ADMINISTRATEUR RÉSEAU
»
Comment configurer le nettoyage automatique des enregistrements dans BigBlueButton
Comment configurer le nettoyage automatique des enregistrements dans BigBlueButton
L'espace de stockage des enregistrements peut rapidement augmenter sur un serveur BigBlueButton très sollicité, mais le terme « nettoyage » peut recouvrir deux réalités bien distinctes : la suppression des données sources brutes après la publication d'un enregistrement, ou la suppression de l'enregistrement lui-même après une période de conservation. Un mauvais choix peut entraîner un gaspillage d'espace disque ou la suppression de contenu prématurée.
Ce guide concerne BigBlueButton 3.0, version actuellement en production selon la documentation officielle (octobre 2026). La documentation de BigBlueButton 4.0 est disponible, mais cette version est encore en développement. Pour les systèmes de production, vérifiez votre version installée bbb-conf --checkavant de copier les paramètres de rétention depuis la documentation d'une autre version. Consultez la documentation d'installation officielle de BigBlueButton .
Choisissez la politique de nettoyage avant de modifier quoi que ce soit.
Il n'existe pas de durée de conservation unique adaptée à tous les contextes. Une université peut avoir besoin d'un accès à la lecture pendant tout un semestre, tandis qu'un serveur de formation interne peut n'avoir besoin des enregistrements que pendant 30 jours. La distinction utile réside entre les données d'enregistrement brutes et les fichiers de lecture publiés .
Choix de nettoyage
Ce que cela permet d'économiser
Compromis principal
Meilleure adaptation
Supprimer les données brutes après publication
Matières premières et matériaux de traitement
Vous perdez la possibilité de reconstruire un enregistrement à partir des données brutes originales une fois celui-ci supprimé.
Serveurs souhaitant maintenir la lecture publiée tout en contrôlant la croissance du disque
Supprimer les enregistrements complets après N jours
Données d'enregistrement publiées et associées
L'enregistrement n'est plus accessible aux utilisateurs.
Des politiques de conservation claires, telles que 30, 60 ou 90 jours.
Suppression contrôlée par l'application
Cela dépend de l'intégration
Plus de flexibilité en matière de politiques, mais aussi une logique d'application et une complexité opérationnelle accrues.
Systèmes multi-locataires ou flux de travail LMS avec règles de rétention par cours
Le guide de personnalisation officiel de BigBlueButton indique que les données brutes sont conservées afin que les administrateurs puissent reconstruire un enregistrement en cas d'échec de traitement, ajouter un autre format d'enregistrement ou récupérer un enregistrement supprimé accidentellement. Cet avantage a un coût en termes de stockage. La même documentation précise que BigBlueButton supprime par défaut les données brutes des enregistrements publiés après 14 jours. Consultez la section « Personnalisation du serveur » de la documentation officielle de BigBlueButton .
Vérifiez l'utilisation actuelle du disque et les enregistrements récents avant de choisir une période de conservation. Il est important de déterminer la vitesse de croissance du répertoire /var/bigbluebutton et les enregistrements dont les utilisateurs ont encore besoin.
Option 1 : conserver les enregistrements publiés mais supprimer les données brutes
Si votre principal problème est la consommation d'espace disque, mais que les utilisateurs ont toujours besoin des liens de lecture, commencez par configurer la conservation des données brutes. Le script de maintenance quotidienne de BigBlueButton se trouve à l'emplacement suivant : [ /etc/cron.daily/bigbluebuttonemplacement du script]. La valeur par défaut documentée est : [valeur par défaut].
published_days=14
Le script appelle également la fonction de nettoyage des enregistrements bruts publiés. Augmenter published_dayscette durée allonge le délai de récupération pour les reconstructions ; la diminuer réduit plus rapidement l’espace de stockage utilisé. Une valeur de 30 jours peut être raisonnable lorsque les administrateurs ont régulièrement besoin de temps pour détecter les défauts d’enregistrement, tandis qu’une période plus courte est plus appropriée lorsque l’espace de stockage est limité et que les enregistrements publiés sont systématiquement vérifiés peu après les réunions.
Il ne faut pas confondre cela avec une politique de conservation complète. Modifier ce paramètre published_daysne signifie pas que l'enregistrement publié disparaîtra après ce nombre de jours. Cela détermine la durée pendant laquelle les données brutes restent disponibles après leur publication.
Le fichier de maintenance quotidienne intégré contient le paramètre published_days utilisé pour les données brutes issues des enregistrements publiés.
Option 2 : supprimer les enregistrements complets antérieurs à un âge fixe
Si votre exigence est que les enregistrements disparaissent après 30 jours, BigBlueButton propose un script de nettoyage quotidien distinct. L'exemple officiel crée ce script /etc/cron.daily/bbb-recording-cleanup, vérifie l'ancienneté des fichiers d'état publiés et des données brutes d'enregistrement, et appelle bbb-record --deletela fonction de nettoyage pour les enregistrements plus anciens que la durée de vie maximale configurée.
Avant d'autoriser la suppression, examinez l'ensemble des candidats. Pour une politique de 30 jours, cette commande en lecture seule vous permet de voir quels fichiers d'état de présentation publiés sont plus anciens que le seuil :
Il ne s'agit pas d'une commande de test BigBlueButton ; c'est simplement une vérification de sécurité du système de fichiers. Utilisez-la pour détecter les erreurs de stratégie avant qu'une tâche automatisée ne supprime des données.
Examinez les enregistrements récents et leurs dates avant d'appliquer une politique de conservation intégrale.
Créer le script de nettoyage
Créer /etc/cron.daily/bbb-recording-cleanup. L'implémentation suivante suit les chemins et l'approche de suppression décrits dans le guide de personnalisation officiel de BigBlueButton, tout en veillant à ce que la valeur de rétention et le fichier journal soient faciles à trouver :
#!/bin/bash
set -u
MAXAGE=30
LOGFILE=/var/log/bigbluebutton/bbb-recording-cleanup.log
NOW=$(date +%s)
shopt -s nullglob
for donefile in /var/bigbluebutton/recording/status/published/*-presentation.done; do
MTIME=$(stat -c %Y "$donefile")
AGE=$(( (NOW - MTIME) / 86400 ))
if [ "$AGE" -gt "$MAXAGE" ]; then
MEETING_ID=$(basename "$donefile")
MEETING_ID=${MEETING_ID%-presentation.done}
echo "$(date --rfc-3339=seconds) deleting $MEETING_ID age=${AGE}d" >> "$LOGFILE"
bbb-record --delete "$MEETING_ID" >> "$LOGFILE" 2>&1
fi
done
for eventsfile in /var/bigbluebutton/recording/raw/*/events.xml; do
MTIME=$(stat -c %Y "$eventsfile")
AGE=$(( (NOW - MTIME) / 86400 ))
if [ "$AGE" -gt "$MAXAGE" ]; then
MEETING_ID=${eventsfile%/events.xml}
MEETING_ID=${MEETING_ID##*/}
echo "$(date --rfc-3339=seconds) deleting raw $MEETING_ID age=${AGE}d" >> "$LOGFILE"
bbb-record --delete "$MEETING_ID" >> "$LOGFILE" 2>&1
fi
done
Définissez MAXAGEcette durée selon votre politique, et non une valeur arbitrairement basse. Par exemple, 30 jours offrent un espace de stockage plus réduit, mais une période de récupération et d'accès plus courte que 90 jours. Si les enregistrements sont soumis à une obligation de conservation formelle, confirmez la politique avec le propriétaire des données avant d'autoriser leur suppression.
Un script de nettoyage peut identifier les anciens enregistrements publiés en fonction de leur ancienneté et transmettre leurs identifiants de réunion internes à bbb-record --delete.La logique de nettoyage doit s'appliquer à l'état d'enregistrement et aux chemins de données brutes de BigBlueButton plutôt qu'à la suppression arbitraire de répertoires par leur nom.
Rendre le script quotidien exécutable
sudo chmod +x /etc/cron.daily/bbb-recording-cleanup
sudo ls -l /etc/cron.daily/bbb-recording-cleanup
Le nom de fichier est volontairement sans extension. Le mécanisme de tâches quotidiennes d'Ubuntu utilise généralement `ls` run-parts, dont les règles de nommage peuvent entraîner l'omission de certains noms de fichiers comportant des points. Conserver le nom tel que documenté bbb-recording-cleanupévite cette source de confusion inutile.
L'avantage principal /etc/cron.dailyréside dans la simplicité, au détriment de la précision temporelle. Si vous souhaitez un nettoyage à une heure de faible trafic précise, une entrée cron pour l'administrateur ou un minuteur systemd permet une planification plus rigoureuse, mais cela relève alors de la personnalisation de votre système d'exploitation et non plus du comportement par défaut documenté par BigBlueButton. Il est donc conseillé de suivre et de tester ce comportement séparément.
Effectuez le nettoyage manuellement une fois avant de faire confiance à l'automatisation.
Après avoir examiné les fichiers candidats, exécutez le script une fois depuis le shell :
BigBlueButton indique bbb-record --delete <internal-meeting-id>que cette commande supprime les données et l'enregistrement d'une réunion. La documentation relative à l'enregistrement précise également que cette commande peut effacer une réunion en cours. Une politique de conservation judicieuse utilise donc un seuil d'ancienneté suffisamment élevé pour qu'une réunion active ne puisse jamais être concernée, et ne supprime que les identifiants trouvés dans les anciens enregistrements. Consultez la documentation officielle sur l'enregistrement et la lecture .
Exécutez manuellement la tâche de nettoyage une fois et consultez son journal avant de vous fier à une exécution quotidienne automatisée.Un journal de nettoyage utile enregistre les identifiants de réunion internes supprimés et la date d'achèvement de la tâche.
Vérifiez que le nettoyage fonctionne comme prévu.
La vérification doit porter à la fois sur les enregistrements visibles par l'utilisateur et sur l'utilisation du disque. Commencez par les commandes d'enregistrement de BigBlueButton :
bbb-record --list-recentAffiche les dix derniers enregistrements. bbb-record --checkVérifie la configuration et les autorisations d'enregistrement dans BigBlueButton 2.5 et versions ultérieures. Ces commandes ne remplacent pas la surveillance du stockage ; il est donc également nécessaire de mesurer l'arborescence des enregistrements.
df -h /var/bigbluebutton
sudo du -sh /var/bigbluebutton/recording /var/bigbluebutton/published
Ne vous attendez pas à ce que l'espace disque utilisé diminue exactement de la taille de lecture affichée aux utilisateurs. Les fichiers bruts, les fichiers de traitement, les fichiers de présentation publiés, les journaux et les données temporaires sont stockés séparément, et le temps de nettoyage peut varier selon les catégories.
Utilisez les commandes de liste d'enregistrements bbb après le nettoyage pour confirmer que les enregistrements attendus restent disponibles.
Comment choisir une période de conservation
Une durée de conservation pertinente dépend de trois contraintes : les attentes des utilisateurs, les besoins de récupération et l’espace de stockage disponible. Une durée de conservation courte réduit la pression sur le stockage, mais laisse moins de temps aux administrateurs pour détecter les erreurs de traitement ou reconstruire les enregistrements. Une durée de conservation longue accroît la flexibilité de récupération, mais nécessite davantage d’espace disque et peut entrer en conflit avec les exigences de minimisation des données.
Conservez la lecture, minimisez le stockage brut : optimisez published_dayset laissez intacts les enregistrements publiés.
Imposer une date d'expiration stricte pour la lecture : utiliser le script de nettoyage quotidien distinct avec une documentation claire MAXAGE.
Il faut des règles par cours ou par client : placez les décisions de rétention dans le LMS ou la couche applicative et utilisez délibérément l’API de BigBlueButton, plutôt que d’imposer une seule limite d’âge à l’échelle du serveur pour chaque enregistrement.
Besoin de flexibilité pour la reconstruction : conserver les données brutes plus longtemps que le minimum requis et s’assurer que la capacité de sauvegarde corresponde à ce choix.
Erreurs courantes à éviter
La première erreur fréquente consiste à croire que cette fonction published_dayssupprime les enregistrements publiés. Elle ne concerne en réalité que les données brutes associées à ces enregistrements. La seconde est d'utiliser rm -rfles répertoires d'enregistrement BigBlueButton comme principal mécanisme de conservation. Cela empêche l'outil d'enregistrement de connaître les identifiants de réunion et peut entraîner des incohérences.
Une autre erreur consiste à définir une période de rétention trop restrictive avant d'avoir mesuré la croissance réelle. Il est conseillé de capturer les données sur au moins plusieurs jours du, dfpuis de choisir une période laissant une marge suffisante pour les semaines particulièrement chargées. Les exigences de production de BigBlueButton nécessitent elles-mêmes un espace de stockage important pour les enregistrements, ce qui nous rappelle que le nettoyage doit être conçu comme une gestion de la capacité, et non comme une réaction d'urgence lorsque le système de fichiers est presque saturé.
Liste de vérification finale
Vérifiez la version de BigBlueButton installée avec bbb-conf --check.
Déterminez si vous avez uniquement besoin d'un nettoyage des données brutes ou d'une suppression complète de l'expiration des enregistrements.
Mesurez l'utilisation actuelle du stockage avant de choisir une période de conservation.
Examinez les anciens enregistrements candidats avant d'autoriser leur suppression.
Créez le script de nettoyage quotidien et rendez-le exécutable.
Exécutez-le manuellement une fois et consultez le journal.
Revérifiez bbb-record --list-recent, bbb-record --check, et l'utilisation du disque.
Documentez la politique de conservation des données afin que les utilisateurs sachent combien de temps la lecture reste disponible.
Pour la plupart des installations BigBlueButton 3.0 sur un seul serveur, la solution la plus simple à gérer consiste à laisser la tâche quotidienne intégrée supprimer les données brutes des enregistrements publiés après une période de récupération, puis à ajouter le bbb-recording-cleanupscript quotidien documenté uniquement lorsque vous souhaitez également que les enregistrements publiés expirent. Cette approche permet de distinguer deux décisions de stockage différentes et de rendre le compromis explicite, au lieu de traiter tous les anciens fichiers d'enregistrement de la même manière.