O backup de dados diminuiu repentinamente, a restauração dos dados diminuídos está anormal, o site não consegue interagir normalmente. Felizmente, o bucket de armazenamento Amazon S3 pode encontrar dados históricos, caso contrário, a perda seria incomensurável.
Houve alguma alteração de configuração nesse período que possa ter afetado a inclusão de uploads em seus backups?
Fiz uma atualização, usei um tema, adicionei um plugin personalizado ao tema (css personalizado), os usuários podem desativar a seleção de cores, usei data.yml, web_only.yml, após restaurar os dados com 262 Mbytes, agora o backup tem apenas 154 Mbytes, esses dados de backup provavelmente ainda estão com problemas
Você mudou para uma configuração de dois contêineres naquele momento ou sempre a utilizou?
Tem sido usado dessa forma, quais são as possíveis causas?
Tentei restaurar meu último backup há alguns dias e o upload no meu painel foi recusado. Senti por um segundo que meu backup tinha sumido, então tentei mais um upload no FTP e adivinha? Restaurado! Mas isso aconteceu da mesma forma e eu gostaria de saber o motivo.
Receio que estou mais familiarizado com a instalação padrão e não tenho certeza se a configuração de dois contêineres tem alguma peculiaridade que possa ser relevante aqui.
Deixe-me passar isso para Installation e ver se conseguimos mais olhares experientes nisso.
(@pfaffman
)
Eu estava usando a instalação padrão antes, mas a instalação padrão tem um problema: toda vez que eu fazia alterações em app.yml, meu site não podia ser acessado normalmente. Se eu usasse data.yml ou web_only.yml, eu poderia fazer alterações em web_only.yml sem afetar o acesso ao site. A instalação padrão tem uma função semelhante? Como usá-la especificamente?
Não. A única diferença é que uma reconstrução reconstrói apenas as partes do rails e do nginx. O banco de dados e o redis permanecem os mesmos. Eles mudam raramente, então não precisam ser reconstruídos. Funciona exatamente da mesma forma. Você entende isso perfeitamente. (A única complicação é quando há uma atualização do postgres ou do redis, o que acontece na ordem de uma vez por ano, embora tenha havido algumas atualizações de banco de dados que ocorreram devido aos requisitos do plugin de IA. Portanto, se você não estivesse usando o plugin de IA, estaria perfeitamente bem, mas se estivesse, receberia erros confusos de banco de dados se não reconstruísse também o contêiner de dados.)
Minha suposição é que eles moveram os ativos para o s3 e, portanto, os uploads locais não estão incluídos. Isso é consistente com o que eles disseram, que conseguiram restaurar coisas do s3. Ou talvez eles tenham excluído algumas postagens que tinham uploads, então esses uploads não foram incluídos em backups subsequentes.
Além disso, pareceu um pouco como se eles tivessem feito um restore e não tivessem esperado que ele terminasse completamente.
Eu usei um plugin de IA. O que devo observar para que os dados de backup possam ser usados? Como devemos lidar com esse tipo de problema
Significa que, desde que data.yml não seja reconstruído, não há problema, ou é necessário usar app.yml, ou esse tipo de problema existe tanto no plano web_only do data.yml quanto no plano app.yml
O problema é que, quando fiz o backup, o contêiner construído pelo data.yml não era compatível e o banco de dados foi atualizado. Se o rebuild do data.yml for atualizado, não haverá problema mesmo que você faça uma grande atualização do banco de dados, e então não haverá problema com o backup e a restauração. Como posso saber que seu banco de dados foi modificado significativamente?
O problema é que, quando fiz o backup, o contêiner construído pelo data.yml não era compatível e o banco de dados foi atualizado. Se o rebuild do data.yml for atualizado, não haverá problema mesmo que você faça uma grande atualização do banco de dados, e então não haverá problema com o backup e a restauração. Como posso saber que seu banco de dados foi modificado significativamente?
@sober, como nota de processo, é muito mais fácil para quem está lendo/querendo ajudar se você incluir uma tradução em inglês em suas postagens. Você poderia editar uma para incluir. ![]()
Agora entendo que o problema foi uma grande atualização do banco de dados que causou problemas de backup.
Quando o Discourse for atualizado, como posso garantir que a versão atualizada seja uma versão beta em vez de uma versão de desenvolvimento? Após o último backup ter dado errado, tenho que me preocupar com as operações de atualização e restauração de backup
O quê? Bem, vou esperar por uma confirmação porque não sei se isso vai quebrar algo aqui.
Eu só quero atualizar o beta2, não o beta2-dev, porque tenho medo que o dev seja instável, e o backup de dados recente não possa ser restaurado normalmente, o que quase causou perda de dados. Usei o backup anterior para backup, mas os dados ainda foram perdidos por um período de tempo.
Eles não são, isso é apenas uma mudança recente no sistema de versionamento. Tecnicamente, você nem deveria ver os rótulos -dev.


