Discourse סקריפט גיבוי ועדכון שבועי אוטומטי (מניעת בעיות בהעלאות S3)

סיכום מבוסס בינה מלאכותית

This discussion centers around a script created by copymonopoly to automate weekly Discourse backups and updates, specifically addressing issues with S3 uploads corrupting the backup process. The script disables S3 uploads, enables Read-Only Mode, performs a backup, re-enables S3 uploads, pulls the latest code changes, and rebuilds the Docker container. copymonopoly explains that backups created with S3 uploads enabled frequently fail during restoration, a problem documented in other Discourse threads, such as the one linked on Meta (:link: https://meta.discourse.org/t/trouble-restoring-backup-sitesetting-upload-s3-base-url-is-failing-because-enable-s3-uploads-was-set-in-database/215966). RoldanLT requested clarification on the S3 issue, and pfaffman suggested that database-only backups might avoid the S3-related errors.

ב-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 שיכולות להיכשל מסיבות שונות.