Cum se configurează curățarea automată a înregistrărilor în BigBlueButton

Spațiul de stocare pentru înregistrări poate crește rapid pe un server BigBlueButton aglomerat, dar „curățarea” poate însemna două lucruri foarte diferite: eliminarea datelor sursă brute după publicarea unei înregistrări sau ștergerea înregistrării publicate după o perioadă de păstrare. Alegerea unei înregistrări greșite poate fie să consume spațiu pe disc, fie să elimine conținut mai devreme decât se așteaptă utilizatorii.

Acest ghid se concentrează pe BigBlueButton 3.0, pe care documentația oficială o listează ca ramură de producție curentă începând cu octombrie 2026. Documentația BigBlueButton 4.0 este disponibilă, dar este încă marcată ca în curs de dezvoltare. Pentru sistemele de producție, confirmați versiunea instalată cu bbb-conf --checkînainte de a copia setările de retenție din documentație pentru o altă ramură. Consultați documentația oficială de instalare a BigBlueButton .

Alegeți politica de curățare înainte de a schimba ceva

Nu există o valoare unică de retenție care să se potrivească fiecărei implementări. O universitate poate avea nevoie de acces la redare pe durata unui semestru, în timp ce un server intern de instruire poate avea nevoie de înregistrări doar timp de 30 de zile. Distincția utilă este între datele brute de înregistrare și fișierele de redare publicate .

Ghidul oficial de personalizare BigBlueButton precizează că datele brute sunt păstrate, astfel încât administratorii să poată reconstrui o înregistrare dacă procesarea eșuează, să adauge un alt format de înregistrare sau să recupereze datele după o ștergere accidentală. Acest avantaj are un cost de stocare. Aceeași documentație precizează că BigBlueButton elimină datele brute pentru înregistrările publicate după 14 zile în mod implicit. Consultați Personalizarea serverului în documentația oficială BigBlueButton .

Opțiunea 1: păstrați înregistrările publicate, dar eliminați datele brute

Dacă problema principală este consumul de spațiu pe disc, dar utilizatorii au nevoie în continuare de linkuri de redare, începeți cu setarea încorporată de păstrare a datelor brute. Scriptul de întreținere zilnică al BigBlueButton se află la /etc/cron.daily/bigbluebutton. Valoarea implicită documentată este:

published_days=14

Scriptul apelează și funcția de curățare a înregistrărilor brute pentru înregistrările publicate. Creșterea valorii published_daysvă oferă o fereastră de recuperare mai lungă pentru reconstrucții; scăderea acesteia reduce utilizarea spațiului de stocare mai rapid. O valoare precum 30 de zile poate fi rezonabilă atunci când administratorii au nevoie în mod obișnuit de timp pentru a descoperi defectele de înregistrare, în timp ce o perioadă mai scurtă este mai potrivită atunci când spațiul de stocare este limitat, iar rezultatul publicat este verificat în mod curent la scurt timp după întâlniri.

Nu confundați aceasta cu o politică de păstrare completă. Modificarea published_daysnu înseamnă că înregistrarea publicată în sine va dispărea după acel număr de zile. Aceasta controlează cât timp datele brute rămân disponibile după publicare.

Opțiunea 2: ștergeți toate înregistrările mai vechi decât o anumită vârstă

Dacă cerința dumneavoastră este „înregistrările trebuie să dispară după 30 de zile”, BigBlueButton documentează un script separat de curățare zilnică. Exemplul oficial creează /etc/cron.daily/bbb-recording-cleanup, verifică vechimea fișierelor de stare publicate și a datelor brute de înregistrare și solicită bbb-record --deleteînregistrări mai vechi decât vechimea maximă configurată.

Înainte de a activa ștergerea, inspectați setul de candidați. Pentru o politică de 30 de zile, această comandă doar pentru citire vă ajută să vedeți ce fișiere de stare a prezentării publicate sunt mai vechi decât pragul:

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

Aceasta nu este o comandă de tip „dry run” pentru BigBlueButton; este pur și simplu o verificare sigură a sistemului de fișiere. Folosește-o pentru a detecta erorile de politică înainte ca o sarcină automată să înceapă ștergerea datelor.

Creați scriptul de curățare

Creați /etc/cron.daily/bbb-recording-cleanup. Următoarea implementare respectă căile și abordarea de ștergere descrise în ghidul oficial de personalizare al BigBlueButton, păstrând în același timp valoarea de retenție și fișierul jurnal ușor de găsit:

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

Setați MAXAGEconform politicii dvs., nu la un număr arbitrar mic. De exemplu, 30 de zile oferă o amprentă de stocare mai mică, dar o fereastră de recuperare și acces mai scurtă decât 90 de zile. Dacă înregistrările fac parte dintr-o cerință formală de păstrare, confirmați politica cu proprietarul datelor înainte de a activa ștergerea.

Faceți scriptul zilnic executabil

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

Numele fișierului nu are intenționat nicio extensie. Mecanismul de funcționare zilnică al Ubuntu folosește în mod obișnuit run-parts, ale cărui reguli de denumire a fișierelor pot duce la omiterea unor nume punctate. Păstrarea numelui documentat bbb-recording-cleanupevită această sursă inutilă de confuzie.

Compromisul /etc/cron.dailyeste simplitatea, mai degrabă decât sincronizarea exactă. Dacă aveți nevoie de curățare la o oră precisă cu trafic redus, o intrare cron pentru root sau un cronometru systemd pot oferi o programare mai strictă, dar aceasta devine propria personalizare a sistemului de operare, mai degrabă decât implicit documentat de BigBlueButton. Urmăriți și testați separat.

Executați curățarea manual o dată înainte de a acorda încredere automatizării

După ce ați analizat fișierele candidate, rulați scriptul o dată din shell:

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

BigBlueButton este documentat bbb-record --delete <internal-meeting-id>ca fiind comanda care elimină datele unei întâlniri și înregistrarea acesteia. Documentația de înregistrare avertizează, de asemenea, că această comandă poate șterge o întâlnire în desfășurare. Prin urmare, o politică de păstrare rezonabilă utilizează un prag de vârstă suficient de mare încât o întâlnire activă să nu poată fi niciodată calificată și șterge doar ID-urile descoperite din artefactele de înregistrare vechi. Consultați documentația oficială Înregistrare și Redare .

Verificați dacă curățarea face ceea ce ați intenționat

Verificarea ar trebui să acopere atât înregistrările vizibile utilizatorului, cât și utilizarea discului. Începeți cu comenzile de înregistrare proprii ale BigBlueButton:

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

bbb-record --list-recentafișează cele mai recente zece înregistrări. bbb-record --checkverifică configurația și permisiunile de înregistrare în BigBlueButton 2.5 și versiunile ulterioare. Nicio comandă nu înlocuiește monitorizarea stocării, așadar măsoară și arborele de înregistrare:

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

Nu vă așteptați ca utilizarea discului să scadă exact cu dimensiunea de redare afișată utilizatorilor. Fișierele media brute, fișierele de procesare, fișierele de prezentare publicate, jurnalele și datele temporare sunt stocate separat, iar timpul de curățare poate diferi între categorii.

Cum să alegi o perioadă de păstrare

O valoare utilă de retenție provine din trei constrângeri: așteptările utilizatorilor, nevoile de recuperare și spațiul de stocare disponibil. Retenția scurtă reduce presiunea asupra spațiului de stocare, dar oferă administratorilor mai puțin timp pentru a descoperi defectele de procesare sau a reconstrui înregistrările. Retenția lungă crește flexibilitatea recuperării, dar necesită mai mult spațiu pe disc și poate intra în conflict cu cerințele de minimizare a datelor.

• Mențineți redarea, reduceți la minimum stocarea în format brut: reglați published_daysși păstrați înregistrările publicate intacte.
• Impuneți o expirare definitivă a redării: utilizați scriptul separat de curățare zilnică cu un fișier MAXAGE.
• Sunt necesare reguli per curs sau per client: plasați deciziile de retenție în stratul LMS sau al aplicației și utilizați API-ul BigBlueButton în mod deliberat, în loc să impuneți o singură vârstă la nivel de server pentru fiecare înregistrare.
• Este nevoie de flexibilitate în reconstrucție: păstrați datele brute mai mult decât minimul și asigurați-vă că capacitatea de backup corespunde acestei alegeri.

Greșeli frecvente de evitat

Prima greșeală frecventă este presupunerea că published_daysșterge înregistrările publicate. Aceasta guvernează doar datele brute asociate cu înregistrările publicate. A doua este utilizarea rm -rfdirectoarelor de înregistrări BigBlueButton ca mecanism principal de păstrare. Aceasta ocolește informațiile instrumentului de înregistrare despre ID-urile întâlnirilor și poate lăsa stări inconsistente.

O altă greșeală este setarea agresivă a retenției înainte de a măsura creșterea reală. Capturați cel puțin câteva zile de dudate df, apoi selectați o perioadă care lasă suficient spațiu pentru săptămânile neobișnuit de aglomerate. Cerințele de producție ale BigBlueButton necesită în sine o stocare substanțială a înregistrărilor, ceea ce ne reamintește că curățarea ar trebui concepută ca o gestionare a capacității, nu ca o reacție de urgență după ce un sistem de fișiere este aproape plin.

Listă de verificare finală

• Confirmați versiunea instalată de BigBlueButton cu bbb-conf --check.
• Decideți dacă aveți nevoie doar de curățarea datelor brute sau de expirarea completă a înregistrării.
• Măsurați utilizarea curentă a spațiului de stocare înainte de a selecta o perioadă de păstrare.
• Verificați înregistrările vechi înainte de a activa ștergerea.
• Creați scriptul de curățare zilnică și faceți-l executabil.
• Rulați-l manual o dată și verificați jurnalul.
• Verificați din nou bbb-record --list-recent, bbb-record --check, și utilizarea discului.
• Documentați politica de păstrare a datelor, astfel încât utilizatorii să știe cât timp rămâne disponibilă redarea.

Pentru majoritatea instalărilor BigBlueButton 3.0 pe un singur server, designul cu cea mai mică întreținere este de a permite jobului zilnic încorporat să elimine datele brute ale înregistrărilor publicate după o fereastră de recuperare, apoi să adauge bbb-recording-cleanupscriptul zilnic documentat doar atunci când este nevoie și ca înregistrările publicate să expire. Acest lucru separă două decizii diferite de stocare și face compromisul explicit în loc să trateze fiecare fișier de înregistrare vechi în același mod.