Planejamento de Backup e Restauração

Suporte
1

Quero garantir uma boa estratégia de backup quando meu site entrar no ar. Estas são as seguintes etapas que implementei. O que estou perdendo?

Backups de Banco de Dados

  • O Discourse faz um backup diário do banco de dados.
  • Um backup adicional do banco de dados via cron é realizado diariamente. (+12 horas do backup baseado na interface do usuário)
  • Os backups são armazenados em um bucket S3 (data center diferente)

Arquivos Principais

Os seguintes são copiados duas vezes por dia para um bucket S3 (data center diferente)

  • discourse/containers/app.yml
  • discourse/shared/standalone/uploads/
  • discourse/shared/standalone/backups/
  • discourse/shared/standalone/ssl/
  • discourse/shared/standalone/letsencrypt/

Os backups de arquivos ocorrem duas vezes por dia, 30 minutos após os backups do banco de dados.

S3: Uploads

  • O backup diário de Uploads é armazenado em um bucket S3 em um data center diferente.

Backups de Servidor

  • Backups semanais de todo o servidor - 4 backups semanais mantidos
  • Armazena anualmente um backup semanal como backup mestre em um local remoto.

Isso deve fornecer todos os dados e configurações necessários para restaurar um servidor no local ou em um novo servidor.

Estou perdendo alguma coisa?

1 curtida
2

Essa é a forma sugerida. Se você fizer backup do seu banco de dados uma vez por dia, estará arriscando no máximo 24 horas de tudo o que aconteceu naquele fórum.

Disseram-me pelo menos duas vezes que não é um problema, mas ninguém jamais explicou por que não. Então, estou fazendo backup do meu banco de dados a cada 6 horas — meu fórum não é tão movimentado, então posso correr esse risco. Para comparar — meu e-commerce faz backup a cada 4 minutos.

1 curtida
3

Como você configurou seu banco de dados para fazer backup com mais frequência? Eu preferiria duas vezes por dia, mas a funcionalidade da interface do usuário só permite diariamente.

4

Você pode ter um cron job (no seu servidor, não no container) executando

docker exec app bash -c "discourse backup"

Se os dados forem realmente críticos, você pode configurar um servidor de replicação postgres e ter cada commit em um segundo servidor.

1 curtida
5

Tenho isto no crontab:

docker exec app discourse backup --sql-only

Este é o próprio comando CLI do Discourse para fazer backup, e fui informado que docker exec app o executa fora do container (app no nome do container, é claro.

E como configurei o S3, ele vai para o mesmo bucket onde os backups “normais” também estão.

Há um pequeno problema… em breve haverá zilhões de backups. Não sei se devo fazer o sql-dump de forma diferente, movê-lo usando aws-cli e depois eliminar tudo o que for mais antigo que um determinado período de tempo. Ou fazer a mesma coisa no VPS.

Mas essa é a maneira mais fácil de obter o sql-dump.

1 curtida
6

Estou assumindo que isso ativa a rotina interna de backup do discourse, então todas as notificações permanecem no lugar.

Você desativa o agendamento de backup na interface do usuário e gerencia tudo via cron? ou, você está fazendo um na interface do usuário e o adicional via cron?

7

Não. Eu faço ambos. Não confio tanto no sistema, nem em mim. Raramente a quantidade de backups é o problema real, a escassez é.

1 curtida
8

Obrigado @Jagster e @pfaffman pela ajuda em configurar um banco de dados adicional via cron. Isso reduz a perda de dados do meu sistema para um pior cenário de 12 horas.

2 curtidas