Discourse Geautomatiseerd Wekelijks Back-up en Update Script (Vermijden van S3 Upload Problemen)

Gemeenschaps wiki Beheerders
1

In Discourse kunnen back-ups die worden gegenereerd terwijl de S3-uploadfunctie is ingeschakeld, vaak niet succesvol worden gebruikt om de site te herstellen, waardoor automatische back-ups effectief ongeldig worden. Om dit probleem aan te pakken, heb ik dit script geschreven dat S3-uploads uitschakelt voordat de back-up wordt gestart, zodat back-upbestanden compleet en bruikbaar zijn. Nadat de back-up is voltooid, schakelt het script S3-uploads weer in om de normale werking en bestandsopslag van de site te behouden.

Bovendien schakelt het script de Read-Only Mode in tijdens het back-up- en updateproces om gegevensschrijfacties te voorkomen en consistentie te garanderen. Ten slotte haalt het automatisch de nieuwste codewijzigingen op en herbouwt het de Docker-container om de onderhoudscyclus te voltooien.

Ik hoop dat dit script andere Discourse-beheerders kan helpen. Feedback en suggesties voor verbetering zijn welkom!

#!/bin/bash

set -e

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

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

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 "Discourse.enable_readonly_mode(Discourse::USER_READONLY_MODE_KEY); puts 'Readonly mode enabled'" >> "$LOG_FILE" 2>&1

log "Disabling S3 uploads..."
sudo docker exec app rails runner "SiteSetting.enable_s3_uploads = false" >> "$LOG_FILE" 2>&1

log "Starting backup..."
if ! sudo docker exec app discourse backup >> "$LOG_FILE" 2>&1; 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_FILE" 2>&1

log "Disabling Read-Only Mode..."
sudo docker exec app rails runner "Discourse.disable_readonly_mode(Discourse::USER_READONLY_MODE_KEY); puts 'Readonly mode disabled'" >> "$LOG_FILE" 2>&1

log "Pulling latest git changes..."
git pull >> "$LOG_FILE" 2>&1

log "Rebuilding container..."
./launcher rebuild app >> "$LOG_FILE" 2>&1

log "Weekly update complete."

exit 0
1 like
2

Hi,

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

3

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 like
4

Ik ben er vrij zeker van dat als je alleen een database-back-up maakt, deze de S3-taken die om verschillende redenen kunnen mislukken niet zal proberen uit te voeren.