Discourse Script hebdomadaire automatisé pour sauvegarde et mise à jour (Évitant les problèmes upload S3)

Dans Discourse, les sauvegardes générées lorsque la fonctionnalité de téléversement S3 est activée ne peuvent souvent pas être utilisées avec succès pour restaurer le site, rendant les sauvegardes automatiques effectivement invalides. Pour résoudre ce problème, j’ai écrit ce script qui désactive les téléversements S3 avant de commencer la sauvegarde, garantissant ainsi que les fichiers de sauvegarde sont complets et utilisables. Une fois la sauvegarde terminée, le script réactive les téléversements S3 pour maintenir les opérations normales du site et le stockage des fichiers.

De plus, le script active le mode lecture seule (Read-Only Mode) pendant le processus de sauvegarde et de mise à jour pour empêcher les écritures de données et assurer la cohérence. Enfin, il récupère automatiquement les dernières mises à jour du code et reconstruit le conteneur Docker pour compléter le cycle de maintenance.

J’espère que ce script pourra aider les administrateurs Discourse. Vos commentaires et suggestions d’amélioration sont les bienvenus !

#!/bin/bash

set -e

# Fichier de log
LOG_FILE="/var/discourse/scripts/weekly_update.log"

# Fonction pour logger les messages
log() {
  echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" 
}

log "=== Mise à jour hebdomadaire de Discourse démarrée ==="

# Se déplacer dans le répertoire de Discourse
cd /var/discourse || { log "Échec du changement de répertoire vers /var/discourse"; exit 1; }

log "Activation du mode lecture seule..."
sudo docker exec app rails runner "SiteSetting.readonly_mode = true; puts 'Mode lecture seule activé'" 

log "Désactivation des téléversements S3..."
sudo docker exec app rails runner "SiteSetting.enable_s3_uploads = false"

log "Démarrage de la sauvegarde..."
# Lancer la sauvegarde
if ! sudo docker exec app discourse backup ; then
  log "Échec de la sauvegarde"
  exit 1
fi
log "Sauvegarde réussie."

log "Réactivation des téléversements S3..."
sudo docker exec app rails runner "SiteSetting.enable_s3_uploads = true"

log "Désactivation du mode lecture seule..."
sudo docker exec app rails runner "SiteSetting.readonly_mode = false; puts 'Mode lecture seule désactivé'"

log "Récupération des derniers changements git..."
git pull 

log "Reconstruction du conteneur..."
./launcher rebuild app 

log "Mise à jour hebdomadaire terminée."

exit 0
1 « J'aime »

Bonjour,

Pouvez-vous s’il vous plaît élaborer ? Quel est le problème spécifiquement ?
L’archive est-elle parfois corrompue avec S3 activé ?

Salut, merci pour votre question !

Oui — le problème est que lorsque enable_s3_uploads est activé pendant la sauvegarde, l’archive résultante ne peut souvent pas être restaurée avec succès. Bien que la raison technique exacte ne soit pas entièrement claire (et ait été discutée dans plusieurs fils de discussion), le processus de restauration échoue fréquemment à moins que S3 ne soit désactivé avant la sauvegarde.

Vous pouvez trouver plusieurs rapports sur Meta en recherchant \"enable_s3_uploads restore\".

Par exemple, ce fil de discussion montre un cas d’échec typique :
:link: Trouble restoring backup--SiteSetting::Upload.s3_base_url is failing--because enable_s3_uploads was set in database

C’est pourquoi mon script désactive temporairement S3 avant la sauvegarde, pour garantir que le résultat soit propre et restaurable.

J’espère que cela clarifie les choses !

1 « J'aime »

Je suis quasiment sûr que si vous effectuez une sauvegarde de la base de données seule, elle n’essaiera pas de réaliser les opérations S3 qui peuvent échouer pour diverses raisons.