Configure automatic backups for Discourse

Documentação Auto-hospedagem
,
131

Backups Automáticos no Backblaze B2

Aqui está como eu configurei para um site hipotético hospedado em example.com

  1. Crie uma conta no Backblaze (no momento, não é necessário inserir pagamento para <10GB, que é gratuito)
  2. Crie um bucket (Backblaze > Armazenamento em Nuvem B2)
    • nome: $nomedosite-discourse-$aleatorio preenchido para 30 caracteres
      • neste exemplo: example-discourse-g87he56ht8vg
      • o Discourse precisa que o nome do bucket contenha apenas letras minúsculas, números e hifens
      • sugiro mantê-lo com 30 caracteres ou menos, pois isso aparece bem na interface web do Backblaze sem quebrar a linha
    • bucket privado
    • ative a criptografia (SSE-B2)
    • ative o bloqueio de objetos
  3. Crie uma chave de aplicativo (Backblaze > Conta > Chaves de Aplicativo)
    • nome da chave: example-discourse
    • nome do bucket (Permitir acesso ao(s) Bucket(s)): example-discourse-g87he56ht8vg
    • capacidades: ler e escrever
    • deixe nomePrefix e validDurationSeconds em branco
  4. Configure as configurações do Discourse B2 (Discourse > Admin > Configurações)
    • backup_location: s3
    • s3_backup_bucket: example-discourse-g87he56ht8vg
    • s3_endpoint: isso é mostrado na página do bucket – certifique-se de adicionar https:// no início
    • s3_access_key_id: (da etapa anterior)
    • s3_secret_access_key: (da etapa anterior)
      • o Backblaze só mostra a chave uma vez (na criação)!
    • aliás, você também pode definir essas variáveis como variáveis de ambiente no seu arquivo YAML do contêiner em vez disso. isso permitiria restaurar com apenas esse arquivo e nada mais:
env:
  ## Backups do Backblaze B2
  # DISCOURSE_BACKUP_LOCATION: 's3' # descomente para recuperar via CLI
  DISCOURSE_S3_ENDPOINT: 'https://....backblazeb2.com'
  DISCOURSE_S3_BACKUP_BUCKET: 'example-discourse-g87he56ht8vg'
  DISCOURSE_S3_ACCESS_KEY_ID: '...'
  DISCOURSE_S3_SECRET_ACCESS_KEY: '...'
  # DISCOURSE_DISABLE_EMAILS: 'non-staff' # descomente para desativar e-mails durante um teste de restauração
  ## você pode restaurar sem nenhum dado além deste arquivo YAML do contêiner.
  ## descomente DISCOURSE_BACKUP_LOCATION acima, construa o contêiner (./launcher rebuild ...),
  ## e então execute isso dentro do contêiner (ele restaurará do bucket B2):
  ##   discourse enable_restore
  ##   discourse restore <example-com-...tar.gz> # escolha o nome do arquivo de restauração navegando na interface web do B2
  ## lembre-se de desativar a restauração depois
  1. Configure a retenção de backup
    • Discourse:
      • backup_frequency: 1 (backups diários neste exemplo, mas você poderia fazer semanais)
      • maximum_backups: ignore esta configuração – deixe o Backblaze cuidar disso :sunglasses:
      • s3_disable_cleanup: true (Impede a remoção de backups antigos do S3 quando há mais backups do que o máximo permitido)
    • Backblaze (vá para as configurações do seu bucket):
      • Bloqueio de Objetos (Política de Retenção Padrão): 7 dias
      • Configurações de Ciclo de Vida (personalizado):
        • fileNamePrefix: default/example-com (opcional)
        • daysFromUploadingToHiding: 8 dias
          • isso deve ser o bloqueio de objeto + 1
        • daysFromHidingToDeleting: 1 dia
          para resumir a retenção neste exemplo:
  • o Discourse cria backups a cada 1 dia
  • cada arquivo de backup é imutável por 7 dias após o upload para o B2 (bloqueio de objeto). isso protege contra acidentes, ransomware, etc.
  • 8 dias após o upload, o bloqueio de objeto no backup expira. como ele se torna mutável novamente, uma regra de ciclo de vida pode ocultar o arquivo de backup
  • a próxima parte da regra de ciclo de vida exclui qualquer arquivo 1 dia após ser ocultado

então você obtém backups diários. o tempo de retenção é de uma semana durante a qual os backups não podem ser excluídos, não importa o quê. então os backups são excluídos 2 dias depois. então, na verdade, um backup vive por cerca de 9 dias.

espero que isso ajude alguém :slight_smile:

em segundo pensamento, talvez seja melhor deixar o Discourse cuidar da retenção (maximum_backups). dessa forma, seus backups não começarão a expirar automaticamente se o Discourse estiver inativo. você não gostaria que um relógio estivesse contando contra eles enquanto tenta se recuperar. se você seguisse esse caminho, poderia definir maximum_backups=8 e s3_disable_cleanup=false neste exemplo e não usar uma política de ciclo de vida no B2. você ainda usaria a política de bloqueio de objeto (7 dias), no entanto.

editar: na verdade, acho que você ainda precisa de uma política de ciclo de vida do B2 porque acho que os arquivos só ficam ‘ocultos’ e não são excluídos quando um cliente S2 os exclui. estou usando a política “Manter apenas a última versão do arquivo”, que é equivalente a daysFromHidingToDeleting=1, daysFromUploadingToHiding=null.

acho que pense sobre isso e decida qual abordagem é a certa para você.

aliás, percebo que há alguma discussão neste post. acho que é informativo como está, mas se alguém quiser, eu poderia fazer outro post um pouco mais simples com minhas recomendações reais.

6 curtidas