Discourse Script Automatico Settimanale di Backup e Aggiornamento (Evitando Problemi di Upload S3)

In Discourse, i backup generati mentre la funzionalità di caricamento S3 è abilitata spesso non possono essere utilizzati con successo per ripristinare il sito, rendendo di fatto non validi i backup automatici. Per affrontare questo problema, ho scritto questo script che disabilita i caricamenti S3 prima di avviare il backup, garantendo che i file di backup siano completi e utilizzabili. Dopo che il backup è terminato, lo script riabilita i caricamenti S3 per mantenere le normali operazioni del sito e l’archiviazione dei file.

Inoltre, lo script abilita la Modalità di Sola Lettura durante il processo di backup e aggiornamento per prevenire scritture di dati e garantire la coerenza. Infine, recupera automaticamente gli ultimi aggiornamenti del codice e ricompila il container Docker per completare il ciclo di manutenzione.

Spero che questo script possa aiutare altri amministratori di Discourse. Feedback e suggerimenti per miglioramenti sono benvenuti!

#!/bin/bash

set -e

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

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

log "=== Aggiornamento Settimanale Discourse Avviato ==="

cd /var/discourse || { log "Impossibile accedere a /var/discourse"; exit 1; }

log "Abilitazione Modalità di Sola Lettura..."
sudo docker exec app rails runner "SiteSetting.readonly_mode = true; puts 'Modalità di sola lettura abilitata'" 

log "Disabilitazione caricamenti S3..."
sudo docker exec app rails runner "SiteSetting.enable_s3_uploads = false" 

log "Avvio backup..."
if ! sudo docker exec app discourse backup 
; then
  log "Backup fallito"
  exit 1
fi
log "Backup riuscito."

log "Abilitazione caricamenti S3..."
sudo docker exec app rails runner "SiteSetting.enable_s3_uploads = true" 

log "Disabilitazione Modalità di Sola Lettura..."
sudo docker exec app rails runner "SiteSetting.readonly_mode = false; puts 'Modalità di sola lettura disabilitata'" 

log "Recupero delle ultime modifiche git..."
git pull 

log "Ricompilazione del container..."
./launcher rebuild app 

log "Aggiornamento settimanale completato."

exit 0
1 Mi Piace

Ciao,

Puoi per favore elaborare su questo? Qual è il problema specifico?
L’archivio è a volte corrotto con S3 abilitato?

Ciao, grazie per la tua domanda!

Sì, il problema è che quando enable_s3_uploads è abilitato durante il backup, l’archivio risultante spesso non può essere ripristinato con successo. Sebbene la ragione tecnica esatta non sia del tutto chiara (ed è stata discussa in diversi thread), il processo di ripristino fallisce frequentemente a meno che S3 non venga disabilitato prima del backup.

Puoi trovare diversi report su Meta cercando \"enable_s3_uploads restore\".

Ad esempio, questo thread mostra un tipico caso di fallimento:
:link: Trouble restoring backup--SiteSetting::Upload.s3_base_url is failing--because enable_s3_uploads was set in database

Ecco perché il mio script disabilita temporaneamente S3 prima del backup, per garantire che il risultato sia pulito e ripristinabile.

Spero che questo chiarisca!

1 Mi Piace

Sono abbastanza sicuro che se fai un backup solo del database, non tenterà di fare le cose S3 che possono fallire per vari motivi.