Discourse سكربت آلي أسبوعي للنسخ الاحتياطي والتحديث (لتجنب مشاكل تحميل S3)

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

بالإضافة إلى ذلك، يقوم البرنامج النصي بتمكين وضع القراءة فقط (Read-Only Mode) أثناء عملية النسخ الاحتياطي والتحديث لمنع كتابة البيانات وضمان الاتساق. أخيرًا، يقوم بسحب آخر تحديثات التعليمات البرمجية تلقائيًا وإعادة بناء حاوية Docker لإكمال دورة الصيانة.

آمل أن يساعد هذا البرنامج النصي زملاء مديري Discourse. نرحب بالتعليقات والاقتراحات للتحسين!

#!/bin/bash

set -e

LOG_FILE="/var/discourse/scripts/weekly_update.log"

log() {
  echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" 
}

log "=== Weekly Discourse Update Started ==="

cd /var/discourse || { log "Failed to cd /var/discourse"; exit 1; }

log "Enabling Read-Only Mode..."
sudo docker exec app rails runner "SiteSetting.readonly_mode = true; puts 'Readonly mode enabled'" 

log "Disabling S3 uploads..."
sudo docker exec app rails runner "SiteSetting.enable_s3_uploads = false"

log "Starting backup..."
if ! sudo docker exec app discourse backup ; then
  log "Backup failed"
  exit 1
fi
log "Backup succeeded."

log "Enabling S3 uploads..."
sudo docker exec app rails runner "SiteSetting.enable_s3_uploads = true"

log "Disabling Read-Only Mode..."
sudo docker exec app rails runner "SiteSetting.readonly_mode = false; puts 'Readonly mode disabled'"

log "Pulling latest git changes..."
git pull 

log "Rebuilding container..."
./launcher rebuild app 

log "Weekly update complete."

exit 0
إعجاب واحد (1)

مرحباً،

هل يمكنك توضيح هذا الأمر؟ ما هي المشكلة تحديداً؟
هل الأرشيف تالف في بعض الأحيان مع تمكين S3؟

أهلاً، شكراً لسؤالك!

نعم - المشكلة هي أنه عند تمكين enable_s3_uploads أثناء النسخ الاحتياطي، فإن الأرشيف الناتج غالباً ما لا يمكن استعادته بنجاح. بينما السبب التقني الدقيق غير واضح تماماً (وقد تمت مناقشته في عدة مواضيع)، فإن عملية الاستعادة غالباً ما تفشل ما لم يتم تعطيل S3 قبل النسخ الاحتياطي.
يمكنك العثور على تقارير متعددة على Meta بالبحث عن \"enable_s3_uploads restore\".

على سبيل المثال، يوضح هذا الموضوع حالة فشل نموذجية:
:link: Trouble restoring backup--SiteSetting::Upload.s3_base_url is failing--because enable_s3_uploads was set in database

لهذا السبب يقوم النص البرمجي الخاص بي بتعطيل S3 مؤقتاً قبل النسخ الاحتياطي، لضمان أن تكون النتيجة نظيفة وقابلة للاستعادة.

آمل أن يساعد هذا في التوضيح!

إعجاب واحد (1)

أعتقد جازمًا أنه إذا قمت بعمل نسخة احتياطية لقاعدة البيانات فقط، فلن يحاول إجراء عمليات S3 التي قد تفشل لأسباب متنوعة.