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 "=== עדכון שבועי של Discourse החל ==="

cd /var/discourse || { log "כשל במעבר לספריית /var/discourse"; exit 1; }

log "מפעיל מצב קריאה בלבד..."
sudo docker exec app rails runner "SiteSetting.readonly_mode = true; puts 'Readonly mode enabled'" ">
  log "מצב קריאה הופעל"

log "משבית העלאות S3..."
sudo docker exec app rails runner "SiteSetting.enable_s3_uploads = false" ">

log "מתחיל גיבוי..."
if ! sudo docker exec app discourse backup ">
  log "הגיבוי נכשל"
  exit 1
fi
log "הגיבוי הצליח."

log "מפעיל העלאות S3..."
sudo docker exec app rails runner "SiteSetting.enable_s3_uploads = true" ">

log "משבית מצב קריאה בלבד..."
sudo docker exec app rails runner "SiteSetting.readonly_mode = false; puts 'Readonly mode disabled'" ">
  log "מצב קריאה הושבת"

log "מושך שינויי git אחרונים..."
git pull ">

log "בונה מחדש את הקונטיינר..."
./launcher rebuild app ">

log "העדכון השבועי הושלם."

exit 0
לייק 1

Hi,

Can you please elaborate on this? What is the issue specifically?
Is the archive corrupt sometimes with S3 enabled?

Hi, thanks for your question!

Yes — the issue is that when enable_s3_uploads is enabled during backup, the resulting archive often cannot be successfully restored. While the exact technical reason isn’t fully clear (and has been discussed in several threads), the restore process frequently fails unless S3 is disabled before backup.

You can find multiple reports on Meta by searching for "enable_s3_uploads restore".

For example, this thread shows a typical failure case:
:link: Trouble restoring backup--SiteSetting::Upload.s3_base_url is failing--because enable_s3_uploads was set in database

That’s why my script temporarily disables S3 before backup, to ensure the result is clean and restorable.

Hope this helps clarify!

לייק 1

אני די בטוח שאם אתה מבצע גיבוי של מסד נתונים בלבד, זה לא ינסה לבצע את פעולות S3 שיכולות להיכשל מסיבות שונות.