Não tenho certeza se devo responder aqui ou criar um novo post: Solicitação de recurso - agendamentos separados para ‘incluir anexos’ versus ‘não incluir anexos’.
Eu adoraria backups diários pequenos, possivelmente até várias vezes ao dia, já que o banco de dados é pequeno. Anexos eu não ficaria devastado em perder uma semana, pois são muito mais limitados e geralmente as pessoas podem encontrar sua origem novamente. Isso poderia aumentar o fator de segurança sem sobrecarregar o armazenamento.
Eu não olhei o código-fonte, mas provavelmente seria uma reformulação, já que as restaurações teriam que ser entidades separadas, ou pelo menos a capacidade de ter pontos de restauração diferentes para as 2 fontes.
Bastante razoável. Assim que começo a considerar ferramentas externas, penso em ‘maneiras externas de realmente estragar tudo’, já que elas são tipicamente capazes de mais estragos do que o console de administração integrado à prova de idiotas (mais ou menos).
Da última vez que eu, e outros, perguntamos a mesma coisa, as respostas foram as mesmas de antes:
um backup diário é suficiente
use ferramentas externas, como scripts e cron
Bem, um backup diário do banco de dados não é suficiente, um a cada hora poderia ser o ideal.
Qualquer ferramenta externa pode fazer o trabalho, isso é verdade. Mas todos os outros aplicativos oferecem backup decente nativamente, mas não o Discourse.
Eu realmente gostaria de saber se o motivo é
“nós simplesmente não queremos, por isso ninguém mais precisa disso”
Se você quer muitos backups com o WordPress (uma plataforma web popular), você precisa usar um plugin de backup que custa dinheiro, então talvez nem todos os outros aplicativos façam isso nativamente. Pelo menos é o que estou fazendo, embora já faz muito tempo que tomei essa decisão, então talvez tenha sido uma má decisão.
A razão é que ter muitos backups é uma forma de encher seu disco, que é um dos motivos mais comuns para um site auto-hospedado cair (o que eu acho que o coloca na categoria “caro”). Então a ideia é que, se você tem habilidades suficientes para gerenciar um zilhão de backups e gerenciar seu espaço em disco, então você provavelmente pode resolver isso de várias maneiras. E se você quiser backups a cada hora, então você precisa que eles sejam apenas backups do banco de dados, em vez de dezenas ou centenas de cópias de seus uploads.
Portanto, backups a cada hora só fazem sentido se você tiver uploads no S3 para que possa fazer backups apenas do banco de dados, e provavelmente enviá-los para o S3 para que você não se preocupe com seu disco local. E então esse é um número bem pequeno de sites auto-hospedados que querem isso.
Se você tem tudo isso implementado, então um plugin que fizesse backups apenas do banco de dados a cada hora não seria mais do que uma ou duas horas de trabalho, ou talvez 2-10 se você não souber como fazer um plugin e tiver que descobrir como criar um trabalho a cada hora.
Isso é verdade. O próprio WordPress não pode fazer muito. É por isso que existem tantos plugins — bons e ruins.
Isso não é verdade. Apenas extras custam, não o backup em si.
Claro, não adianta fazer backup de arquivos ou do sistema em si, com tanta frequência. O banco de dados em si é um jogo totalmente diferente. Deve ser feito pelo menos a cada 15 minutos se houver mais tráfego.
A questão é muito simples: quanto conteúdo você pode perder.
Se a perda máxima de dados que você pode suportar for tão pequena, você pode considerar o uso de uma solução de replicação do Postgres em vez de fazer backups com tanta frequência.
Existe algum outro dado que eu não conheço? Ou você usa dados no sentido mais amplo, incluindo todos os arquivos; sistema, Docker/Discourse/etc, carregados?
Esses arquivos podem ser recuperados facilmente ou com pequenos custos — bem, exceto os carregados, mas é para isso que temos o S3 .
Então é, em sua maioria, pequeno em tamanho, mas é o maior se pensarmos no fórum em si. Mas, por alguma razão, voltamos a isto:
Eu realmente gostaria de saber se o principal problema aqui é técnico ou mental. Ou se isso é realmente parte do modelo de negócios e, se o backup for fácil e funcionar, a hospedagem perderá um argumento de venda — e eu não sei se existe tal argumento de venda. Estou apenas tentando entender por que um backup melhor é uma questão tão importante, mesmo que já tenha sido solicitado antes.
Não há necessidade de suspeitar que exista uma estratégia ou plano maligno por trás disso. Não acho que haja muito interesse em backups mais frequentes. Se houvesse, alguém teria escrito um plugin para isso. Seriam algumas horas de trabalho. Não vejo o Marketplace inundado de solicitações para isso.
Acho que se resume a:
para fóruns pequenos, você não perderá muitos dados de qualquer maneira, pois não há muita novidade em um dia, então backups mais frequentes não valem o esforço
para fóruns maiores, backups mais frequentes consumirão desempenho e armazenamento
para fóruns realmente grandes, você desejará procurar soluções diferentes (como replicação para um servidor de banco de dados de espera ativa)
Não se esqueça que as chances de realmente precisar de um backup também são muito pequenas. Na história do Communiteq (mais de 8 anos), só precisamos restaurar um backup uma vez e isso foi apenas porque estávamos impacientes e não queríamos esperar algumas horas por uma recuperação do sistema de arquivos.
*) (excluindo restaurações a pedido do cliente onde eles apenas queriam reverter alterações, principalmente em fóruns não produtivos, e excluindo nosso teste mensal de restauração)
Então, se eu procurar aqui, não encontrarei nenhum tópico em que o Discourse tenha travado por algum motivo e a única solução tenha sido restaurar a partir de um backup?
Mas é bom saber que o Discourse é tão sólido que não precisa de backup atualizado. Bem, sabemos que isso não é totalmente verdade.
Então o círculo se fecha e voltamos ao ponto de partida:
E a terceira opção. Enquanto eu, de fato, estou testando o Discourse, aqui e por conta própria, não estou disposto a pagar por uma funcionalidade tão básica.
Bem, estamos falando aqui sem nenhum comentário da equipe. De novo
Este é o caminho. Siga Executando o Discourse com um servidor PostgreSQL separado para executar sua própria instância do PostgreSQL e lidar com backup e alta disponibilidade conforme achar melhor, se o backup diário não for suficiente para seu caso de uso.
Estou pensando em US$ 250-500, dependendo de quão configurável é e quanto trabalho é necessário no front-end. Na verdade, não olhei o que seria preciso. @RGJ pode fazer por menos; ele muitas vezes me surpreendeu com a rapidez com que consegue fazer as coisas.
EDIT: OH, este tópico está fechado. Se você estiver interessado, pode me contatar ou postar em Marketplace.
.
