Script de Backup e Atualização Semanal Automatizado do Discourse (Evitando Problemas de Upload do S3)

No Discourse, backups gerados enquanto a funcionalidade de upload S3 está habilitada frequentemente não podem ser usados com sucesso para restaurar o site, tornando os backups automáticos efetivamente inválidos. Para resolver este problema, escrevi este script que desabilita os uploads S3 antes de iniciar o backup, garantindo que os arquivos de backup estejam completos e utilizáveis. Após o término do backup, o script reabilita os uploads S3 para manter as operações normais do site e o armazenamento de arquivos.

Adicionalmente, o script habilita o Modo Somente Leitura durante o processo de backup e atualização para prevenir escritas de dados e garantir consistência. Finalmente, ele baixa automaticamente as últimas atualizações de código e reconstrói o contêiner Docker para completar o ciclo de manutenção.

Espero que este script possa ajudar outros administradores do Discourse. Feedback e sugestões de melhoria são bem-vindos!

#!/bin/bash

set -e

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

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

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 "SiteSetting.readonly_mode = true; puts 'Readonly mode enabled'" 

log "Disabling S3 uploads..."
sudo docker exec app rails runner "SiteSetting.enable_s3_uploads = false"

log "Starting backup..."
if ! sudo docker exec app discourse backup 
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 "Disabling Read-Only Mode..."
sudo docker exec app rails runner "SiteSetting.readonly_mode = false; puts 'Readonly mode disabled'"

log "Pulling latest git changes..."
git pull 

log "Rebuilding container..."
./launcher rebuild app 

log "Weekly update complete."

exit 0
1 curtida

Olá,

Você pode, por favor, elaborar sobre isso? Qual é o problema especificamente?
O arquivo está corrompido às vezes com o S3 habilitado?

Olá, obrigado pela sua pergunta!

Sim — o problema é que, quando enable_s3_uploads está ativado durante o backup, o arquivo resultante muitas vezes não pode ser restaurado com sucesso. Embora a razão técnica exata não esteja totalmente clara (e tenha sido discutida em vários tópicos), o processo de restauração falha frequentemente, a menos que o S3 seja desativado antes do backup.

Você pode encontrar vários relatórios no Meta pesquisando por "enable_s3_uploads restore".

Por exemplo, este tópico mostra um caso de falha típico:
:link: Trouble restoring backup--SiteSetting::Upload.s3_base_url is failing--because enable_s3_uploads was set in database

É por isso que meu script desativa temporariamente o S3 antes do backup, para garantir que o resultado seja limpo e restaurável.

Espero que isso ajude a esclarecer!

1 curtida

Tenho quase certeza de que se você fizer um backup apenas do banco de dados, ele não tentará fazer as coisas do S3 que podem falhar por vários motivos.