How to Set Up Automated Recording Cleanup in BigBlueButton

Recording storage can grow quickly on a busy BigBlueButton server, but “cleanup” can mean two very different things: removing raw source data after a recording has been published, or deleting the published recording itself after a retention period. Choosing the wrong one can either waste disk space or remove content earlier than your users expect.

This guide focuses on BigBlueButton 3.0, which the official documentation lists as the current production branch as of October 2026. BigBlueButton 4.0 documentation is available but is still marked as in development. For production systems, confirm your installed version with bbb-conf --check before copying retention settings from documentation for another branch. See the official BigBlueButton installation documentation.

Choose the cleanup policy before changing anything

There is no single retention value that fits every deployment. A university may need semester-long playback access, while an internal training server may only need recordings for 30 days. The useful distinction is between raw recording data and published playback files.

BigBlueButton’s official customization guide says raw data is retained so administrators can rebuild a recording if processing fails, add another recording format, or recover from an accidental deletion. That benefit has a storage cost. The same documentation states that BigBlueButton removes raw data for published recordings after 14 days by default. See Server Customization in the official BigBlueButton documentation.

Option 1: keep published recordings but remove raw data

If your main problem is disk consumption but users still need playback links, start with the built-in raw-data retention setting. BigBlueButton’s daily maintenance script is located at /etc/cron.daily/bigbluebutton. The documented default is:

published_days=14

Lo script richiama anche la funzione di pulizia delle registrazioni non elaborate per le registrazioni pubblicate. Aumentando questo valore published_dayssi ottiene una finestra di ripristino più lunga per le ricostruzioni; diminuendolo, si riduce più rapidamente l'utilizzo dello spazio di archiviazione. Un valore come 30 giorni può essere ragionevole quando gli amministratori hanno regolarmente bisogno di tempo per individuare i difetti di registrazione, mentre un periodo più breve è più appropriato quando lo spazio di archiviazione è limitato e l'output pubblicato viene controllato regolarmente subito dopo le riunioni.

Non bisogna confondere questa impostazione con una politica di conservazione completa. La modifica published_daysnon significa che la registrazione pubblicata scomparirà dopo quel numero di giorni. Regola invece per quanto tempo i dati grezzi rimangono disponibili dopo la pubblicazione.

Opzione 2: eliminare le registrazioni complete più vecchie di un'età fissa

Se il requisito è che "le registrazioni devono scomparire dopo 30 giorni", BigBlueButton documenta uno script di pulizia giornaliera separato. L'esempio ufficiale crea uno script /etc/cron.daily/bbb-recording-cleanup, controlla l'età dei file di stato pubblicati e dei dati di registrazione grezzi e richiama bbb-record --deletele registrazioni più vecchie dell'età massima configurata.

Prima di abilitare l'eliminazione, esamina l'insieme dei candidati. Per una policy di 30 giorni, questo comando di sola lettura ti aiuta a vedere quali file di stato della presentazione pubblicati sono più vecchi della soglia:

sudo find /var/bigbluebutton/recording/status/published \
  -type f -name '*-presentation.done' -mtime +30 -print

Questo non è un comando di prova di BigBlueButton; è semplicemente un controllo sicuro del filesystem. Usalo per individuare eventuali errori nelle policy prima che un processo automatizzato inizi a eliminare i dati.

Crea lo script di pulizia

Crea /etc/cron.daily/bbb-recording-cleanup. L'implementazione seguente segue i percorsi e l'approccio di eliminazione descritti nella guida ufficiale alla personalizzazione di BigBlueButton, mantenendo al contempo il valore di conservazione e il file di log facilmente reperibili:

#!/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

Imposta MAXAGEil periodo di conservazione in base alle tue policy, non a un numero arbitrario e basso. Ad esempio, 30 giorni occupano meno spazio di archiviazione, ma offrono una finestra di recupero e accesso più breve rispetto a 90 giorni. Se le registrazioni sono soggette a un requisito formale di conservazione, conferma la policy con il responsabile dei dati prima di abilitarne la cancellazione.

Rendi eseguibile lo script giornaliero

sudo chmod +x /etc/cron.daily/bbb-recording-cleanup
sudo ls -l /etc/cron.daily/bbb-recording-cleanup

Il nome del file non ha intenzionalmente alcuna estensione. Il meccanismo di gestione dei processi giornalieri di Ubuntu utilizza comunemente run-parts, le cui regole per i nomi dei file possono causare l'esclusione di alcuni nomi che iniziano con un punto. Mantenere il nome documentato bbb-recording-cleanupevita questa inutile fonte di confusione.

Il compromesso /etc/cron.dailyè la semplicità piuttosto che la precisione temporale. Se hai bisogno di eseguire la pulizia in un orario preciso di basso traffico, una voce cron di root o un timer systemd possono fornire una pianificazione più precisa, ma questo diventa una personalizzazione del tuo sistema operativo anziché l'impostazione predefinita documentata da BigBlueButton. Monitora e testa separatamente.

Eseguire la pulizia manualmente almeno una volta prima di affidarsi all'automazione.

Dopo aver esaminato i file candidati, esegui lo script una volta dalla shell:

sudo /etc/cron.daily/bbb-recording-cleanup
sudo tail -n 50 /var/log/bigbluebutton/bbb-recording-cleanup.log

BigBlueButton descrive questo bbb-record --delete <internal-meeting-id>comando come quello che rimuove i dati e la registrazione di una riunione. La documentazione relativa alla registrazione avverte inoltre che questo comando può cancellare anche una riunione in corso. Pertanto, una politica di conservazione sensata prevede l'utilizzo di una soglia di età sufficientemente ampia da impedire che una riunione attiva la superi, ed elimina solo gli ID rilevati da vecchie registrazioni. Consultare la documentazione ufficiale relativa alla registrazione e alla riproduzione .

Verifica che la pulizia stia funzionando come previsto.

La verifica dovrebbe riguardare sia le registrazioni visibili all'utente sia l'utilizzo del disco. Iniziate con i comandi di registrazione di BigBlueButton:

sudo bbb-record --list-recent
sudo bbb-record --check

bbb-record --list-recentMostra le dieci registrazioni più recenti. bbb-record --checkVerifica la configurazione e le autorizzazioni di registrazione in BigBlueButton 2.5 e versioni successive. Nessuno dei due comandi sostituisce il monitoraggio dello spazio di archiviazione, quindi è necessario misurare anche la struttura ad albero delle registrazioni:

df -h /var/bigbluebutton
sudo du -sh /var/bigbluebutton/recording /var/bigbluebutton/published

Non aspettatevi che l'utilizzo del disco si riduca esattamente della dimensione di riproduzione mostrata agli utenti. I file multimediali non elaborati, i file di elaborazione, i file di presentazione pubblicati, i registri e i dati temporanei vengono archiviati separatamente e i tempi di pulizia possono variare a seconda della categoria.

Come scegliere un periodo di conservazione

Un valore di conservazione utile deriva da tre vincoli: le aspettative degli utenti, le esigenze di ripristino e lo spazio di archiviazione disponibile. Una conservazione breve riduce la pressione sullo spazio di archiviazione, ma lascia agli amministratori meno tempo per individuare difetti di elaborazione o ricostruire le registrazioni. Una conservazione lunga aumenta la flessibilità di ripristino, ma richiede più spazio su disco e potrebbe essere in conflitto con i requisiti di minimizzazione dei dati.

• Mantieni la riproduzione, riduci al minimo lo spazio di archiviazione non elaborato: accorda published_dayse lascia intatte le registrazioni pubblicate.
• Imporre una scadenza rigida per la riproduzione: utilizzare lo script di pulizia giornaliera separato con una documentazione chiara MAXAGE.
• Se hai bisogno di regole specifiche per corso o per cliente, metti le decisioni relative alla conservazione dei dati nel livello LMS o nell'applicazione e usa l'API di BigBlueButton in modo mirato, invece di imporre un'unica età a livello di server per ogni registrazione.
• Necessità di flessibilità nella ricostruzione: conservare i dati grezzi più a lungo del minimo e assicurarsi che la capacità di backup sia adeguata a tale scelta.

Errori comuni da evitare

Il primo errore comune è presumere che published_dayselimini le registrazioni pubblicate. In realtà, gestisce solo i dati grezzi associati alle registrazioni pubblicate. Il secondo errore consiste rm -rfnell'utilizzare le directory di registrazione di BigBlueButton come meccanismo di conservazione principale. Questo aggira la conoscenza degli ID delle riunioni da parte dello strumento di registrazione e può lasciare uno stato incoerente.

duUn altro errore consiste nell'impostare un periodo di conservazione troppo restrittivo prima di misurare la crescita effettiva. Acquisite dati per almeno diversi giorni df, quindi selezionate un periodo che lasci un margine sufficiente per le settimane di picco. Gli stessi requisiti di produzione di BigBlueButton richiedono una notevole capacità di archiviazione per le registrazioni, il che ci ricorda che la pulizia dovrebbe essere progettata come gestione della capacità, non come reazione di emergenza quando un filesystem è quasi pieno.

Lista di controllo finale

• Conferma la versione di BigBlueButton installata con bbb-conf --check.
• Decidi se hai bisogno solo di pulire i dati grezzi o se è sufficiente la completa cancellazione delle registrazioni.
• Prima di selezionare un periodo di conservazione, valutare l'utilizzo attuale dello spazio di archiviazione.
• Prima di autorizzare la cancellazione, esamina le registrazioni precedenti.
• Crea lo script di pulizia giornaliera e rendilo eseguibile.
• Eseguilo manualmente una volta e controlla il registro.
• Ricontrolla e l'utilizzo del disco bbb-record --list-recent.bbb-record --check
• Documenta la politica di conservazione dei dati in modo che gli utenti sappiano per quanto tempo i contenuti riprodotti rimangono disponibili.

Per la maggior parte delle installazioni di BigBlueButton 3.0 su un singolo server, la configurazione che richiede meno manutenzione prevede che il processo giornaliero integrato rimuova i dati grezzi delle registrazioni pubblicate dopo un intervallo di tempo per il ripristino, e che lo bbb-recording-cleanupscript giornaliero documentato venga aggiunto solo quando è necessario che anche le registrazioni pubblicate scadano. In questo modo si separano due diverse decisioni relative all'archiviazione e si rende esplicito il compromesso, anziché trattare tutti i vecchi file di registrazione allo stesso modo.