Não é muito arriscado fazer apenas 1 backup por dia? Se algo acontecer com o servidor e o último backup foi feito ontem, o que eu faço? Usuários registrados entre ontem e hoje, eles não serão mais registrados? Acho que é melhor fazer backups com mais frequência, talvez a cada hora. Mas, nesse caso, você tem que colocar o site em modo somente leitura antes de fazer um backup? Agradeço desde já!
3 curtidas
+1 para isso, novamente. O Discourse é o único sistema dinâmico onde se pode automatizar o backup do banco de dados apenas uma vez por dia.
Não espero que isso mude no core tão cedo. Tive conversas sobre mudar o padrão para mais de uma vez por semana e isso não vai acontecer.
Acho que o que pode ser bom é um plugin que adicionaria uma configuração do site para fazer backups apenas do banco de dados em algumas horas (não há razão para manter um zilhão de cópias de uploads não compressíveis em todos esses backups completos). Se você estiver interessado, me envie uma mensagem privada ou pergunte no marketplace.
2 curtidas
Se precisar de uma recuperação de desastres melhor, recomendo seguir Executando o Discourse com um servidor PostgreSQL separado e executar o PostgreSQL por conta própria, onde você pode controlar a alta disponibilidade exata de que precisa, como réplicas de sincronização ao vivo, recuperação de ponto no tempo e backups mais frequentes.
3 curtidas
Posso perguntar o motivo desta política, é técnico ou mais uma questão de classe? Um intervalo de 24 horas entre os backups é um problema bastante crítico em fóruns de alto tráfego. Ou isso é algo que vocês oferecem apenas a clientes pagantes?
1 curtida
Executar o Discourse com um servidor PostgreSQL separado reduz a velocidade por estar em um servidor diferente?
1 curtida
Claro, essa é uma solução. Uma solução bastante rara entre os aplicativos, no entanto. No mundo PHP/MySQL, fazer backup do banco de dados usando cron seria muito fácil, mas novamente - nesse mundo, todo aplicativo pode fazer isso por conta própria, com ou sem algum plugin.
Sim, sou um pouco mais do que um usuário final comum 
mas tenho um entendimento muito superficial de como docker, rails etc. funcionam e, para mim, a situação em que tarefas comuns são quase impossíveis é realmente difícil de entender. Claro, talvez seja por causa das minhas limitações, mas não sou o único a me perguntar isso.
Bem. Não teremos backups de banco de dados facilmente no futuro próximo ou médio, entendi.
1 curtida
Você também pode configurar backups do PostgreSQL com cron. Nada diferente aqui.
Não de forma relevante. Cada instância do Discourse que hospedamos, como esta aqui, usa um banco de dados em um servidor dedicado.
2 curtidas
Só faço duas perguntas para entender melhor.
- O banco de dados é a única coisa que você precisa para restaurar tudo, certo? O backup que é feito diariamente através das configurações, o backup é apenas do banco de dados?
- O fórum deve ficar em modo somente leitura ao fazer o backup para o banco de dados? Ou pode ser feito sem nenhum problema, a qualquer momento?
Muito obrigado desde já!
2 curtidas
As configurações ficam no banco de dados.
Tecnicamente, você também quer fazer backup da pasta de uploads e da definição do site app.yml. No entanto, isso geralmente é tratado tendo o app.yml em controle de versão e os uploads em um serviço de armazenamento de objetos.
Não é necessário modo somente leitura.
4 curtidas
Então, assumindo que eu tenha o banco de dados em um servidor separado e faça backups desse banco de dados a cada hora. Se eu também fizer backup, a partir das configurações no painel de administração, apenas os arquivos incluindo o arquivo app.yml e a pasta uploads seriam incluídos no backup, mas não o banco de dados, certo? @Falco
1 curtida
O backup incluirá o banco de dados e os uploads (se não estiverem no S3). O app.yml não está no backup, pois o Discourse não pode lê-lo.
O que eu recomendo para a maioria das pessoas é ter os backups no S3 e o app.yml em algum lugar que você possa obter em caso de emergência. Então, você pode construir um novo contêiner com o app.yml e restaurá-lo a partir da linha de comando. Mas se você tiver as habilidades técnicas para fazer backup/restaurar o postgres com alguma outra ferramenta, e as imagens no S3 (ou talvez você as tenha em backup de outra forma também), então você pode simplesmente reconstruir o contêiner e estará de volta.
Ou talvez você queira ter vários servidores postgres espelhados continuamente e, em seguida, providenciar a troca automática para o backup se o primário falhar.
Existem um zilhão de maneiras de fornecer backups mais frequentes do que o Discourse oferece. Se você precisar de backups mais frequentes, então você precisará fazê-los de outra forma.
2 curtidas
Um outro ponto aqui é risco e manutenção: se você usar a solução diária pronta para uso, é provável que ela seja mais robusta e confiável como solução de backup do que se você configurar a sua própria. E se algo der errado com a sua própria solução e você descobrir apenas quando for tarde demais? Pelo menos com a solução padrão, você tem centenas de sites testando-a diariamente.
Dado que não tive uma única experiência de corrupção em vários sites em 4 anos, o risco de realmente precisar do backup em primeiro lugar também é baixo…
Talvez outros possam mencionar riscos maiores, mas provavelmente o maior risco são problemas devido ao preenchimento do servidor? Então, fique de olho no espaço? Configure um alerta?
3 curtidas
Então, pelo que entendi, a melhor maneira é manter tudo separado.
Servidor principal para rodar o Discourse. Depois um servidor para PostgreSQL e S3 (ou qualquer outro serviço de object storage) para os uploads.
O arquivo app.yml me parece que não muda com frequência, então você só precisa salvá-lo uma vez. Ou no máximo algumas vezes durante o mês.
Isso permite que você faça backups dos seus arquivos, até de uma forma mais organizada.
Se for assim, acho que a escolha deles de não implementar múltiplos backups diários no core faz sentido. Por outro lado, quem tem necessidades complexas certamente fará configurações particulares como essa. E no final você só precisa refazer a instalação (com o app.yml salvo em algum lugar) e depois reconectá-lo ao banco de dados e ao S3 para os uploads dos dados. Os backups ficam nesses 2 servidores separadamente, então é fácil de gerenciar para mim. Acho uma solução bem justa.
Obrigado a todos pela explicação.
3 curtidas
Há outro tópico aqui: Configure automatic backups for Discourse - #113 by Tris20
@pfaffman fez algumas recomendações lá com links. Isso me levou à linha de comando como uma forma de agendar backups mais frequentes, o que para mim é uma solução bastante razoável:
Note que com esta solução você poderia combinar tudo em um script Python para também agendar uma cópia do arquivo yaml, etc., ao mesmo tempo.
2 curtidas
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.