如何在 BigBlueButton 中設定自動錄製清理

在繁忙的 BigBlueButton 伺服器上，錄製儲存空間可能會迅速增長，但「清理」一詞的含義卻截然不同：一是錄製內容發布後刪除原始來源數據，二是錄製內容在保留期結束後直接刪除。選擇錯誤的方式可能會浪費磁碟空間，或導致使用者內容過早刪除。

本指南重點介紹 BigBlueButton 3.0，官方文件顯示，截至 2026 年 10 月，此版本為目前正式版分支。 BigBlueButton 4.0 的文檔也已發布，但仍處於開發階段。對於生產系統，請bbb-conf --check在從其他分支的文件複製保留設定之前，先確認您已安裝的版本。請參閱BigBlueButton 官方安裝文件。

在更改任何內容之前，請先選擇清理策略。

沒有一個統一的保留期限適用於所有部署場景。例如，大學可能需要長達一個學期的回放存取權限，而內部培訓伺服器可能只需要保留30天的錄影。區分原始錄影資料和已發布的回放文件至關重要。

BigBlueButton 的官方自訂指南指出，原始資料會被保留，以便管理員在處理失敗時重建錄製內容、添加其他錄製格式或從意外刪除中恢復。但這種做法會消耗一定的儲存空間。該文件還指出，預設情況下，BigBlueButton 會在發布錄製內容 14 天後刪除其原始資料。請參閱BigBlueButton 官方文件中的「伺服器自訂」部分。

方案一：保留已發布的錄音，但刪除原始數據

如果主要問題是磁碟空間佔用，但使用者仍然需要播放鏈接，請先嘗試內建的原始資料保留設定。 BigBlueButton 的每日維護腳本位於 [此處應填寫腳本地址] /etc/cron.daily/bigbluebutton。文檔中記錄的預設值為：

published_days=14

該腳本還會呼叫已發布錄製檔案的原始錄製清理功能。增加此值published_days可以延長重建的恢復視窗；減少此值可以更快地減少儲存空間佔用。如果管理員通常需要時間來發現錄製缺陷，那麼 30 天可能是合理的值；而如果儲存空間有限，並且通常會在會議結束後不久檢查已發布的輸出，則較短的期限更為合適。

請勿將此與完整的資料保留策略混淆。更改此策略published_days並不意味著已發布的記錄本身會在指定天數後消失。它控制的是原始資料在發布後保留的時間。

選項 2：刪除超過固定期限的完整錄音

如果您的要求是“錄製內容必須在 30 天後刪除”，BigBlueButton 文件中提供了一個單獨的每日清理腳本。官方範例會建立腳本/etc/cron.daily/bbb-recording-cleanup，檢查已發佈狀態檔案和原始錄製資料的發佈時間，並尋找bbb-record --delete超過配置的最大期限的錄製內容。

啟用刪除功能前，請檢查候選集。對於 30 天策略，此唯讀命令可協助您查看哪些已發布的演示狀態檔案早於閾值：

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

這並非 BigBlueButton 的試運行命令；它只是一個安全的檔案系統檢查。在自動化作業開始刪除資料之前，請使用此命令來擷取策略錯誤。

建立清理腳本

創建/etc/cron.daily/bbb-recording-cleanup。以下實作遵循 BigBlueButton 官方自訂指南中所述的路徑和刪除方法，同時保持保留值和日誌檔案易於找到：

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

請根據您的策略進行設置MAXAGE，而不是隨意設定一個很低的數值。例如，30 天的儲存期限雖然佔用空間較小，但復原和存取視窗也比 90 天短。如果錄影資料屬於正式的保留期限，請在啟用刪除功能前與資料擁有者確認策略。

使每日腳本可執行

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

檔案名稱特意沒有副檔名。 Ubuntu 的每日作業機制通常使用 `/etc/usr/local/bin` run-parts，其檔案名稱規則可能會導致一些以點號開頭的檔案名稱被跳過。保留文件中指定的檔案名稱bbb-recording-cleanup可以避免這種不必要的混淆。

這種方式的權衡之處/etc/cron.daily在於簡單易用而非精確計時。如果您需要在流量較低的特定時間段進行清理，可以使用 root 使用者編寫的 cron 條目或 systemd 定時器來實現更精確的調度，但這屬於您自己的作業系統自訂，而非 BigBlueButton 文件中記錄的預設設定。請單獨追蹤和測試。

在信任自動化功能之前，請先手動執行一次清理程序。

審核完候選檔案後，從 shell 執行一次腳本：

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

BigBlueButton 文件bbb-record --delete <internal-meeting-id>中將該命令描述為刪除會議資料及其錄製內容的命令。錄製文件也警告說，此命令可能會清除正在進行的會議。因此，合理的保留策略會使用足夠長的保留期限，以確保正在進行的會議永遠不會滿足保留期限的要求，並且僅刪除從舊錄製檔案中識別出的 ID。請參閱官方的錄製和回放文件。

確認清理工作是否如預期進行。

驗證應涵蓋使用者可見的錄製內容和磁碟使用情況。首先從 BigBlueButton 自身的錄製指令開始：

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

bbb-record --list-recent顯示最近十筆錄製記錄。bbb-record --check檢查 BigBlueButton 2.5 及更高版本中的錄製配置和權限。這兩個命令都不能取代儲存監控，因此還需要檢查錄製樹：

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

請勿期望磁碟使用量會隨著使用者看到的播放檔案大小而精確下降。原始媒體、處理文件、已發布的演示文件、日誌和臨時資料是分別儲存的，不同類別的清理時間可能有所不同。

如何選擇保留期限

合理的保留期限取決於三個限制條件：使用者預期、復原需求和可用儲存空間。較短的保留期限可以降低儲存壓力，但留給管理員發現處理缺陷或重建記錄的時間較少。較長的保留期限可以提高復原的靈活性，但需要更多磁碟空間，並且可能與資料最小化要求相衝突。

• 保留播放功能，最大限度地減少原始儲存：調整published_days並保留已發布的錄音。
• 強制執行硬性播放過期：使用單獨的每日清理腳本，並附有清晰的文件說明MAXAGE。
• 需要按課程或按客戶制定規則：將保留決策放在 LMS 或應用程式層，並特意使用 BigBlueButton 的 API，而不是強制每個錄製內容使用一個伺服器範圍的年齡。
• 需要重建靈活性：保留原始資料的時間比最低要求更長，並確保備份容量與該選擇相符。

避免的常見錯誤

第一個常見的錯誤是假設它published_days會刪除已發布的錄製內容。實際上，它只控制與已發布錄製內容關聯的原始資料。第二個常見的錯誤是將rm -rf其作為 BigBlueButton 錄製目錄的主要保留機制。這樣做會繞過錄製工具對會議 ID 的識別，並可能導致狀態不一致。

另一個誤解是在衡量實際成長之前就設定過高的保留期限。至少要收集幾天的du數據df，然後選擇一個能為異常繁忙的幾週留出足夠緩衝空間的期限。 BigBlueButton 的生產需求本身就需要大量的記錄儲存空間，這提醒我們，清理工作應該被設計成容量管理的一部分，而不是檔案系統幾乎滿時的緊急應變措施。

最終檢查清單

• 使用以下指令確認已安裝的 BigBlueButton 版本bbb-conf --check。
• 確定您是只需要清理原始數據，還是需要徹底清除過期記錄。
• 在選擇保存期限之前，先測量目前的儲存使用情況。
• 啟用刪除功能前，請先查看舊的錄音候選記錄。
• 建立每日清理腳本並使其可執行。
• 手動運行一次並查看日誌。
• bbb-record --list-recent重新檢查bbb-record --check磁碟使用情況。
• 制定保留策略，以便用戶了解播放內容可以保留多長時間。

對於大多數單伺服器 BigBlueButton 3.0 安裝，維護成本最低的設計方案是讓內建的每日作業在恢復視窗期後刪除已發布錄製文件的原始數據，然後bbb-recording-cleanup僅在需要讓已發布錄製文件過期時才添加文件中記錄的每日腳本。這樣就將兩種不同的儲存決策分開，並明確了權衡取捨，而不是以相同的方式處理每個舊錄製檔案。