Modo correto de proteger/reservar cópia do Discourse em servidor auto-hospedado?

Olá,

Em um servidor auto-hospedado, quais são as melhores maneiras de evitar que nosso fórum desapareça para sempre? Como fazer backup de forma adequada e segura dos nossos dados preciosos?

Em um tópico agora excluído, @falco disse:

Fazer snapshots do sistema de arquivos não é suportado e pode resultar em perda de dados.

Além disso, sobre o recurso de backup da Hetzner, a empresa afirma:

recomendamos que você desligue seu servidor para garantir a consistência dos dados no disco.

Então, imagino que essa não seja realmente uma solução recomendada… Ou é?

No meu fórum, uso o rclone e sincronizo minhas pastas locais de backup com uma pasta do Google Drive.

Se meu servidor explodir, tenho meus backups semanais no Google Drive.
Se meus backups locais desaparecerem e o rclone excluir os backups no Drive após sincronizar minha pasta agora vazia, meus backups excluídos ainda estarão disponíveis, pois estarão na lixeira do Google Drive.

Portanto, sinto que essa é uma maneira razoavelmente boa de proteger os dados do meu fórum.

Mas será que é realmente? Existe alguma outra solução confiável e fácil de instalar?
Sobre o rclone: ele é compatível com muitos sistemas de armazenamento. Existem algumas opções melhores para armazenar e sincronizar nossos backups?

Nunca haverá uma forma 100% segura de armazenar dados. Tendo isso claro, o Discourse possui um processo de backup excelente que roda em uma base programável.

Se eu não confio muito em dispositivos e posso aumentar os gastos mensais, começaria transferindo os backups para o S3, ativando a replicação do S3. A partir daí, teria um script que copia esses dados para minha máquina local e, talvez uma vez por mês, transferiria tudo para um disco externo.

Com isso, você tem vários pontos de falha que não falharão todos ao mesmo tempo. A confiabilidade do S3 é bastante alta; além disso, sua máquina local deve estar em bom estado, já que você a usa diariamente e ela não falhou (mas pode falhar, e com certeza mais rápido do que uma falha generalizada no S3).

Como essa abordagem segura não se baseia em segurança da informação (criptografia, etc.), a melhor maneira é ter várias cópias em vários lugares.

Se você sincronizar remotamente /var/discourse/containers e /var/discourse/shared/standalone/backups, estará seguro. Se o seu servidor sair do ar, você precisará apenas do(s) arquivo(s) yml do container e do backup mais recente. Recomendo backups diários. Se você for especialmente esperto e dedicado, pode configurar um processo de limpeza no destino do rsync que mantenha backups semanais, mensais e anuais.

Acabei de escrever isto: Best Practices for Backups

Veja também isto:

Faça backup automaticamente para o Amazon S3, que é integrado.

Usamos rsync há anos e funciona muito bem para nós. Fazemos o rsync dos nossos backups todos os dias para um backup fora do local que controlamos e gerenciamos, então, se o datacenter sofrer um desastre, temos todos os dados :slight_smile:

Além disso, ao pensar em backups e segurança, lembre-se de que a segurança da TI consiste em três domínios principais:

  • disponibilidade
  • integridade
  • confidencialidade

Ao fazer backup dos seus dados, você precisa considerar todos esses três domínios.

Se você tiver um requisito alto de confidencialidade, fazer backup em soluções de terceiros (e em nuvens que não estejam sob seu controle administrativo estrito e pertençam a outros) pode não ser a melhor opção para você.

Segurança não é uma solução única para todos e é baseada no seu modelo único de gerenciamento de riscos. Isso também é composto por três áreas principais:

  • ameaça
  • vulnerabilidade
  • criticidade

É a interseção desses três domínios que ajuda a definir sua estratégia de backup e recuperação.

  • Alguns sites estão mais sujeitos a ameaças do que outros devido ao seu conteúdo ou domínio (modelo de negócios), enquanto outros não despertam muito interesse dos criminosos.

  • Algumas pessoas sabem como hospedar com segurança, instalar as últimas correções de segurança e proteger seu sistema de arquivos, etc., tornando-as menos vulneráveis do que aquelas que não são tão conhecedoras (ou apenas preguiçosas) nessa área.

  • Algumas pessoas operam sites e fóruns extremamente críticos. Se o site cair, por exemplo, elas podem perder muito dinheiro em um único dia (ou até em uma hora), ou a integridade de sua marca será comprometida.

  • Outras, se o site cair, talvez apenas algumas pessoas notem ou se importem, e nenhum dinheiro seja perdido.

Portanto, sem transformar este assunto divertido em um tratado sobre segurança, você deve entender seus próprios requisitos de gerenciamento de riscos com base no seu modelo de negócios e fatores de risco únicos, e não no modelo de gerenciamento de riscos de outras pessoas.

Uma solução única não serve para todos… e esta é uma das lições mais importantes que profissionais de TI podem aprender sobre segurança da TI (mas muito poucos realmente entendem). Backups e recuperação são uma parte fundamental dessa equação.

A título de informação: nunca confiamos nossos backups a terceiros (nunca) e sempre os mantemos em um local seguro sob nosso controle técnico e administrativo.


Como uma história paralela, um amigo meu é um dos melhores mergulhadores em cavernas (exploradores) do mundo. Quando ele mergulha e explora cavernas subaquáticas, ele tem redundância dupla e tripla (gás, máscaras, computadores, luzes, baterias, facas, scooters e muito mais). Já vi ele estocar mais de 40 cilindros de gás e carregar consigo pelo menos dois scooters subaquáticos. Ele sabe como gerenciar riscos debaixo d’água.

NO ENTANTO, esse mesmo explorador mundialmente famoso de cavernas subaquáticas nunca faz backup do computador de mesa e frequentemente vai online porque seu laptop travou e ele perdeu todos os seus dados. Ele diz que não se importa se perder suas apresentações em PowerPoint… então essa é a estratégia de gerenciamento de riscos pessoal dele. Ele valoriza muito mais a própria vida do que alguns arquivos digitais.

Tal é a vida…


Então, para responder à sua pergunta: temos hospedagem própria há quase 30 anos. Sempre mantemos nossos backups fora do local usando rsync e até sftp em um servidor ao qual temos acesso, e nunca tivemos problemas em 30 anos de servidores na Internet. Tenho até uma cópia extra na minha rede doméstica, em um pequeno Mac Mini, como dispositivo de armazenamento privado. Isso é o que considero “seguro”… para o meu modelo de gerenciamento de riscos.

Obrigado por todas essas informações :+1:t6:

Fico me perguntando por que nem mencionei o S3 :thinking: talvez eu estivesse pensando inconscientemente em métodos de backup gratuitos… Mesmo tendo uma assinatura do Google Drive :upside_down_face:

Dito isso, como posso estimar corretamente o custo do S3 em relação ao armazenamento de backups do Discourse?
Não tenho certeza de como preencher os campos da calculadora:


No meu caso, meus backups (com uploads) têm cerca de 1 GB, e eu faria backups diários, com retenção de 4 a 7 dias, suponho.

Outra coisa que não mencionei é que gostaria que meu co-administrador também tivesse acesso aos backups remotos.
Atualmente, no meu Google Drive, compartilhei com ele o diretório onde meus backups estão armazenados.
É possível compartilhar o acesso aos backups do S3 também?

Espere custos de 7 GB-mês (mais uma margem para crescimento) por mês, com uma taxa adicional de transferência sempre que precisar acessar uma das cópias de backup.

Enviar ou recuperar um backup = 1 solicitação?