Discourse Automated Weekly Backup and Update Script (Avoiding S3 Upload Issues)

In Discourse, backups generated while the S3 upload feature is enabled often cannot be used successfully to restore the site, rendering automatic backups effectively invalid. To address this issue, I wrote this script which disables S3 uploads before starting the backup, ensuring that backup files are complete and usable. After the backup finishes, the script re-enables S3 uploads to maintain normal site operations and file storage.

Additionally, the script enables Read-Only Mode during the backup and update process to prevent data writes and ensure consistency. Finally, it automatically pulls the latest code updates and rebuilds the Docker container to complete the maintenance cycle.

I hope this script can help fellow Discourse administrators. Feedback and suggestions for improvement are welcome!

#!/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

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 Like

I’m pretty sure that if you make a database-only backup it won’t try to do the S3 stuff that can fail for various reasons.