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

สคริปต์นี้ยังเรียกใช้ฟังก์ชันการล้างข้อมูลการบันทึกดิบสำหรับการบันทึกที่เผยแพร่แล้ว การเพิ่มค่า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 มักใช้run-partsซึ่งกฎการตั้งชื่อไฟล์อาจทำให้ชื่อที่มีจุดบางชื่อถูกข้ามไป การใช้ชื่อตามที่ระบุไว้bbb-recording-cleanupจะช่วยหลีกเลี่ยงความสับสนที่ไม่จำเป็นนี้ได้

ข้อดีของการใช้วิธีนี้/etc/cron.dailyคือความเรียบง่ายมากกว่าความแม่นยำในเรื่องเวลา หากคุณต้องการล้างข้อมูลในช่วงเวลาที่มีการใช้งานน้อยอย่างแม่นยำ คุณสามารถใช้ cron entry หรือ systemd timer เพื่อกำหนดเวลาที่แม่นยำยิ่งขึ้น แต่การตั้งค่านี้จะกลายเป็นการปรับแต่งระบบปฏิบัติการของคุณเอง ไม่ใช่ค่าเริ่มต้นที่ BigBlueButton ระบุไว้ ควรติดตามและทดสอบแยกต่างหาก

ควรทำการล้างข้อมูลด้วยตนเองหนึ่งครั้งก่อนที่จะไว้วางใจระบบอัตโนมัติ

หลังจากตรวจสอบไฟล์ของผู้สมัครแล้ว ให้รันสคริปต์หนึ่งครั้งจากเชลล์:

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แสดงรายการบันทึก 10 รายการล่าสุดbbb-record --checkตรวจสอบการตั้งค่าการบันทึกและสิทธิ์การเข้าถึงใน BigBlueButton เวอร์ชัน 2.5 ขึ้นไป คำสั่งทั้งสองนี้ไม่สามารถทดแทนการตรวจสอบพื้นที่จัดเก็บข้อมูลได้ ดังนั้นควรตรวจสอบโครงสร้างการบันทึกด้วยเช่นกัน

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

อย่าคาดหวังว่าปริมาณการใช้ดิสก์จะลดลงเท่ากับขนาดไฟล์ที่แสดงให้ผู้ใช้เห็นอย่างแม่นยำ ไฟล์มีเดียต้นฉบับ ไฟล์ประมวลผล ไฟล์งานนำเสนอที่เผยแพร่แล้ว บันทึก และข้อมูลชั่วคราวจะถูกจัดเก็บแยกกัน และระยะเวลาในการล้างข้อมูลอาจแตกต่างกันไปในแต่ละหมวดหมู่

วิธีการเลือกช่วงเวลาการเก็บรักษาข้อมูล

ค่าการเก็บรักษาข้อมูลที่มีประโยชน์นั้นมาจากข้อจำกัดสามประการ ได้แก่ ความคาดหวังของผู้ใช้ ความต้องการในการกู้คืน และพื้นที่จัดเก็บข้อมูลที่มีอยู่ การเก็บรักษาข้อมูลในระยะเวลาสั้นจะช่วยลดภาระการจัดเก็บข้อมูล แต่จะทำให้ผู้ดูแลระบบมีเวลาน้อยลงในการค้นหาข้อบกพร่องในการประมวลผลหรือสร้างบันทึกใหม่ การเก็บรักษาข้อมูลในระยะยาวจะเพิ่มความยืดหยุ่นในการกู้คืน แต่ต้องใช้พื้นที่ดิสก์มากขึ้นและอาจขัดแย้งกับข้อกำหนดในการลดปริมาณข้อมูล

• รักษาการเล่นไฟล์ ลดพื้นที่จัดเก็บข้อมูลดิบให้น้อยที่สุด:ปรับแต่งpublished_daysและคงไฟล์บันทึกที่เผยแพร่แล้วไว้เหมือนเดิม
• บังคับใช้การหมดอายุการเล่นอย่างเข้มงวด:ใช้สคริปต์การล้างข้อมูลรายวันแยกต่างหากพร้อมเอกสารอธิบายที่MAXAGEชัดเจน
• จำเป็นต้องมีกฎเฉพาะสำหรับแต่ละหลักสูตรหรือแต่ละลูกค้า:กำหนดการตัดสินใจเกี่ยวกับการเก็บรักษาข้อมูลไว้ใน LMS หรือเลเยอร์แอปพลิเคชัน และใช้ API ของ BigBlueButton อย่างรอบคอบ แทนที่จะบังคับใช้ระยะเวลาการเก็บรักษาข้อมูลแบบเดียวกันกับทุกการบันทึกทั่วทั้งเซิร์ฟเวอร์
• ต้องมีความยืดหยุ่นในการสร้างใหม่:เก็บข้อมูลดิบไว้นานกว่าระยะเวลาขั้นต่ำ และตรวจสอบให้แน่ใจว่าความจุในการสำรองข้อมูลสอดคล้องกับตัวเลือกนั้น

ข้อผิดพลาดทั่วไปที่ควรหลีกเลี่ยง

ข้อผิดพลาดทั่วไปข้อแรกคือ การเข้าใจผิดว่าpublished_daysฟังก์ชันนี้จะลบการบันทึกที่เผยแพร่แล้ว แต่ความจริงแล้วมันมีผลเฉพาะกับข้อมูลดิบที่เกี่ยวข้องกับการบันทึกที่เผยแพร่แล้วเท่านั้น ข้อที่สองคือ การใช้rm -rfฟังก์ชันนี้กับไดเร็กทอรีการบันทึกของ BigBlueButton เป็นกลไกการเก็บรักษาหลัก ซึ่งจะทำให้เครื่องมือบันทึกไม่ทราบรหัสการประชุม และอาจทำให้เกิดสถานะที่ไม่สอดคล้องกันได้

อีกหนึ่งข้อผิดพลาดคือการตั้งค่าระยะเวลาการเก็บรักษาข้อมูลสูงเกินไปก่อนที่จะวัดอัตราการเติบโตที่แท้จริง ควรบันทึกข้อมูลอย่างน้อยหลายวันduจากdfนั้นเลือกช่วงเวลาที่เผื่อพื้นที่ไว้มากพอสำหรับสัปดาห์ที่มีการใช้งานมากเป็นพิเศษ ข้อกำหนดการใช้งานจริงของ BigBlueButton เองก็ต้องการพื้นที่จัดเก็บข้อมูลสำหรับการบันทึกจำนวนมาก ซึ่งเป็นการย้ำเตือนว่าการล้างข้อมูลควรได้รับการออกแบบให้เป็นการจัดการความจุ ไม่ใช่การตอบสนองฉุกเฉินหลังจากระบบไฟล์ใกล้เต็มแล้ว

รายการตรวจสอบขั้นสุดท้าย

• ตรวจสอบเวอร์ชัน BigBlueButton ที่ติดตั้งด้วยbbb-conf --check.
• ตัดสินใจว่าคุณต้องการแค่ล้างข้อมูลดิบ หรือต้องการลบข้อมูลทั้งหมดเมื่อหมดอายุการบันทึก
• ควรตรวจสอบปริมาณการใช้งานพื้นที่จัดเก็บข้อมูลในปัจจุบันก่อนเลือกช่วงเวลาการเก็บรักษาข้อมูล
• ตรวจสอบรายการบันทึกเก่าก่อนที่จะเปิดใช้งานการลบ
• สร้างสคริปต์ทำความสะอาดประจำวันและทำให้สคริปต์นั้นสามารถเรียกใช้งานได้
• เรียกใช้งานด้วยตนเองหนึ่งครั้ง แล้วตรวจสอบบันทึกการทำงาน
• ตรวจสอบbbb-record --list-recentการbbb-record --checkใช้งานดิสก์อีกครั้ง
• จัดทำเอกสารเกี่ยวกับนโยบายการเก็บรักษาข้อมูลเพื่อให้ผู้ใช้ทราบว่าไฟล์วิดีโอจะสามารถใช้งานได้นานเท่าใด

สำหรับระบบ BigBlueButton 3.0 แบบเซิร์ฟเวอร์เดี่ยวส่วนใหญ่ การออกแบบที่ต้องการการบำรุงรักษาน้อยที่สุดคือ การปล่อยให้โปรแกรมทำงานประจำวันลบข้อมูลดิบของการบันทึกที่เผยแพร่แล้วหลังจากช่วงเวลาการกู้คืน จากนั้นจึงเพิ่มbbb-recording-cleanupสคริปต์ประจำวันที่ระบุไว้ในเอกสารเฉพาะเมื่อคุณต้องการให้การบันทึกที่เผยแพร่หมดอายุด้วย วิธีนี้จะแยกการตัดสินใจเกี่ยวกับการจัดเก็บข้อมูลสองแบบออกจากกัน และทำให้เห็นข้อดีข้อเสียอย่างชัดเจน แทนที่จะจัดการไฟล์บันทึกเก่าทุกไฟล์ในลักษณะเดียวกัน