Este tópico evoluiu posteriormente para ‘Restaurar Falha’ a partir da 4ª postagem, que é o problema principal agora. Você pode ignorar as 4 primeiras postagens.
Configurei meus uploads para o Aws S3 anos atrás/desde o início.
Mesmo quando (até onde sei) nunca ativei a opção de incluir os uploads do S3 em meus backups, ontem, quando escolhi incluir ‘Uploads’ em meus backups, recebi isso em meus logs:
Isso levanta algumas discrepâncias curiosas, que me deixam perplexo:
Ontem à noite, ativei a opção em minhas Configurações de Administrador para incluir ‘Uploads’ em meus Backups. E então, quando visualizei minha pasta local ‘Shared Uploads’ através do WinScp, ela tinha pouco menos de 100 arquivos em apenas 1x pasta (nenhuma outra pasta 2x, 3x existe lá, posso compartilhar SS se necessário). Então, por que os logs de backup mostram cerca de 3 mil arquivos baixados. (‘Falha ao baixar’ é outro problema/dor de cabeça nesses logs, mas isso é ‘outro’). Agora, se está baixando esses arquivos do armazenamento local, onde existem tantos arquivos? E se está baixando do S3, então, a) por que está baixando de lá, porque eu nunca mudei essa opção no console Rails para incluir dados do S3 nos backups, nem criei nenhuma opção semelhante na seção Env do meu arquivo yml.
Então, hoje mudei essa opção no Rails Console para ‘True’. E agora, quando executei o trabalho de backup, ele mostrou os mesmos cerca de 3,2 mil arquivos baixados, cerca de 100 ‘Falha ao baixar’. Mas quando verifiquei em meu bucket Aws S3, ele tinha quase 10 vezes mais, 32 mil arquivos de cerca de 3 GB. Então, por que não está baixando todos esses arquivos?
Não há uma maneira de verificar/sincronizar todos esses dados e, possivelmente, saber quais discrepâncias estão ocorrendo e onde?
Agora estou muito confuso, o que devo fazer. Meu objetivo final é mudar meu armazenamento aws (muito caro) para alguma versão mais barata (o próprio Hetzner, onde meu VPS está rodando, é muito, muito barato, então posso aumentar o armazenamento do meu servidor principal também).
Mesmo quando minha pasta ‘Uploads’ (no bucket Aws S3) tem mais de 3 GB (3,2 mil arquivos), por que os backups ficam com pouco menos de 1 GB (com apenas 2,9 mil arquivos baixados no backup), mesmo após habilitar a opção ‘include_s3_uploads_in_backup’ através do console Rails?
Essa configuração baixa os arquivos para um diretório temporário e os inclui no backup. Ela não os coloca no diretório de uploads. Para colocá-los no diretório de uploads, você precisa restaurar o backup. Eu faria isso em um novo servidor para que, se algo der errado, seu servidor original ainda esteja intacto.
Parece que alguns arquivos podem estar faltando. Você tem postagens com imagens faltando? Outra possibilidade é que a tabela de uploads inclua uploads que não são mais referenciados nas postagens, então essas imagens ausentes não importam.
Se forem apenas cerca de 100, provavelmente não é um grande problema.
Ou pode ser que um bug em algum momento tenha limpado (excluído) arquivos que deveriam ter sido mantidos.
Para ver os arquivos que ele baixou, você precisará baixar o arquivo de backup e ver o que ele inclui. Restaure seu backup para um novo servidor para ver como funciona.
Mas o ponto principal é por que o backup tem pouco menos de 1 GB (com apenas 3100 arquivos), mesmo quando a pasta ‘Uploads’ do S3 sozinha tem 3,2 GB e 32 mil arquivos. (Os logs de backup mostram claramente que ele baixou apenas cerca de 10%, 3 mil arquivos).
[Acho muito complicado para mim criar uma nova configuração do Discourse com um domínio diferente para testar isso, embora eu ache super fácil criar um snapshot e, se necessário, reverter meu site, que tem pouquíssimo tráfego, em 5 minutos sem nenhum problema]
Bem, pensei que mesmo depois de alterar a opção no Rails C, por que não adicionar esta linha no yml também DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true, pensando que talvez isso chamasse todos os meus uploads do Aws S3.
Mas, depois de alterar essa opção no yml, reconstruir o contêiner, executar o backup, descobri as mesmas linhas nos logs de backup (3000 downloads de mídia com cerca de 100 falhas).
E quando tentei restaurar (ainda não alterei nenhuma configuração de upload/S3 nas minhas configurações de Administrador), ele deu erro.
Então, desabilitei os uploads do S3 e tentei restaurar meu backup de 1 GB (o backup ainda está na AWS S3), e falhou novamente. O que pode estar dando errado aqui?
Além disso, após a falha na restauração, fui desconectado e, quando me reconectei, uma faixa informou que todos os e-mails não pertencentes à equipe foram desabilitados. E quando tentei acessar o log pelo link recebido em meu e-mail, o arquivo não foi encontrado/está inacessível (a página de erro definida por mim é exibida).
Quando estava tentando restaurar, pouco antes de ser desconectado, eu estava vendo estas mensagens de log:
[2024-08-19 04:12:58] 'Bathinda_Helper' iniciou a restauração!
[2024-08-19 04:12:58] Marcando restauração como em execução...
[2024-08-19 04:12:58] Verificando se /var/www/discourse/tmp/restores/default/2024-08-19-041258 existe...
[2024-08-19 04:12:59] Baixando arquivo para o diretório tmp...
Na tentativa subsequente ‘FAILED-restore’, consegui clicar no link do log pouco antes de ser desconectado. Aqui está:\nlog- failed restore.txt (98.9 KB)\n\nFiz algumas experiências e novos uploads estão de fato sendo criados no meu servidor local ubuntu. Mas a restauração deles do S3 para o local está falhando. Mas o fato é que alguns posts que verifiquei continuam mostrando as imagens do S3 (aquelas que não estão faltando).\n\nPor favor, me guie.
Por favor, ajude. A restauração está falhando novamente.
Além disso, após a ‘Restauração Falhada’, mesmo quando faço login com o mesmo administrador, não consigo acessar o anexo ‘Log.txt’. Em vez disso, ele mostra a página não disponível/a página de erro da minha configuração.
Na verdade, tentei fazer exatamente o mesmo que nas suas capturas de tela na postagem referida logo acima. De qualquer forma, agora farei apenas o ‘Discourse restore’.
Como entendi/espero, não preciso fornecer nenhum caminho para o arquivo de backup (.tz) em lugar nenhum, ele o pegaria automaticamente da minha pasta de backup do servidor local.
