كيفية إعداد التنظيف التلقائي للتسجيلات في BigBlueButton

قد يزداد حجم مساحة تخزين التسجيلات بسرعة على خادم BigBlueButton ذي الاستخدام المكثف، ولكن "التنظيف" قد يعني أمرين مختلفين تمامًا: إزالة بيانات المصدر الخام بعد نشر التسجيل، أو حذف التسجيل المنشور نفسه بعد فترة الاحتفاظ المحددة. قد يؤدي اختيار الخيار الخاطئ إما إلى إهدار مساحة القرص أو إزالة المحتوى قبل الموعد الذي يتوقعه المستخدمون.

يركز هذا الدليل على BigBlueButton 3.0، والذي تُشير إليه الوثائق الرسمية باعتباره الإصدار الإنتاجي الحالي اعتبارًا من أكتوبر 2026. تتوفر وثائق 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لا يعني اختفاء التسجيل المنشور نفسه بعد مرور عدد معين من الأيام، بل يتحكم في مدة بقاء البيانات الأولية متاحة بعد النشر.

الخيار الثاني: حذف التسجيلات الكاملة التي يزيد عمرها عن عمر محدد

إذا كان شرطك هو "حذف التسجيلات بعد 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

اسم الملف لا يحتوي على امتداد عمدًا. تستخدم آلية المهام اليومية في أوبونتو عادةً امتدادًا run-parts، والذي قد تتسبب قواعد تسمية الملفات فيه في تجاهل بعض الأسماء التي تحتوي على نقاط. لذا، فإن الاحتفاظ بالاسم الموثق bbb-recording-cleanupيجنبنا هذا الالتباس غير الضروري.

يكمن التنازل في /etc/cron.dailyالبساطة لا في التوقيت الدقيق. إذا كنت بحاجة إلى تنظيف النظام في ساعة محددة ذات حركة مرور منخفضة، فيمكنك استخدام إدخال cron رئيسي أو مؤقت systemd لتوفير جدولة أكثر دقة، ولكن هذا يصبح تخصيصًا لنظام التشغيل الخاص بك بدلاً من الإعداد الافتراضي الموثق من 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>الأمرَ الذي يُزيل بيانات الاجتماع وتسجيله. كما تُحذّر وثائق التسجيل من أن هذا الأمر قد يمحو اجتماعًا جاريًا. لذا، تعتمد سياسة الاحتفاظ المناسبة حدًا زمنيًا كبيرًا بما يكفي بحيث لا يُحتسب أي اجتماع نشط ضمن هذا الحد، وتحذف فقط المعرّفات المُكتشفة من التسجيلات القديمة. راجع وثائق التسجيل والتشغيل الرسمية .

تأكد من أن عملية التنظيف تقوم بما هو مطلوب.

ينبغي أن يشمل التحقق كلاً من التسجيلات التي يراها المستخدم واستخدام القرص. ابدأ بأوامر التسجيل الخاصة ببرنامج 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.
• الحاجة إلى قواعد لكل دورة أو لكل عميل: ضع قرارات الاحتفاظ في نظام إدارة التعلم أو طبقة التطبيق واستخدم واجهة برمجة تطبيقات 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البرنامج النصي اليومي الموثق فقط عند الحاجة إلى انتهاء صلاحية التسجيلات المنشورة. هذا يفصل بين قرارين مختلفين للتخزين ويجعل المفاضلة واضحة بدلاً من التعامل مع كل ملف تسجيل قديم بنفس الطريقة.