Se precisar de ajuda para identificar a causa raiz de problemas como este, por favor, me avise. Fico feliz em ajudar.
Então, tentei restaurar meu backup de 2,2 GB e obtive isso — a restauração falhou:
EXCEÇÃO: 44 postagens não foram remapeadas para o novo URL de upload S3. A migração S3 falhou para o banco de dados ‘default’.
Estou na versão 2.6b6, uma versão bastante recente. O site é antigo, de 2016.
De vez em quando, nos deparamos com backups nos quais o remapeamento automático e a migração para o S3 falham por vários motivos.
Este é um tópico antigo, então alguma recomendação para ação corretiva? Ter um backup que não consigo realmente usar para restaurar me deixa um pouco preocupado.
Edição: Acabei de perceber que posso estar no tópico errado, já que isso parece ser o mesmo problema
Tentei novamente e ainda estou falhando na restauração com o erro 44 posts não foram remapeados.
A desativação temporária dos uploads para o S3 antes do backup (proposta por @RGJ) não resolve o problema, e atualmente não tenho um esquema de backup funcional, o que é bastante grave.
Alguma sugestão sobre o que tentar?
Ok, este é o caso mais estranho que já vi até agora. Eu esbarrei neste post.
https://meta.discourse.org/t/using-object-storage-for-uploads-s3-clones/148916/160?u=ljpp
Depois de perder horas com isso, defini o DISCOURSE_CDN_URL apenas por curiosidade, um recurso que meu site não utiliza. O backup foi restaurado com sucesso.
Qual é a importância desse parâmetro, neste cenário? @Falco @pfaffman
EDIT:
Retiro o que disse. Após o sucesso no teste, fiz um backup fresco da produção e, mais uma vez, comecei a migrar para um novo servidor. Falhou novamente, mas a mensagem de erro mudou.
EXCEPTION: rake posts:missing_uploads identificou 3 problemas. A migração para o S3 falhou para o banco de dados ‘default’.
EDIT2:
Então continuei investigando o banco de dados e encontrei esses 3 posts.
- 2 eram imagens muito antigas, que foram publicadas inicialmente, mas depois um moderador substituiu as imagens por uma versão modificada. Elas eram de 2016 e 2018.
- Mas o último foi estranho. Era um post muito recente, de apenas algumas semanas atrás, feito por mim, e continha um link https:// oneboxed para um servidor de desenvolvimento que não existe mais. Então, um link quebrado quebra o processo de restauração.
Eu simplesmente excluí esses posts manualmente.
Agora, novamente, uma execução de teste mostra que um backup pode realmente ter sucesso. Vamos ver.
@ljpp Parece que estou em uma situação semelhante, com uma restauração falhando com:
EXCEÇÃO: 1 post não foi remapeado para o novo URL de upload do S3. A migração do S3 falhou para o banco de dados ‘default’.
Você poderia detalhar como encontrou e excluiu os posts problemáticos? Quais comandos foram usados?
Ele deletou as postagens em questão.
Mas você formatou sua instalação, então não pode fazer isso, certo?
Eu tenho este problema restaurando meu banco de dados. Como você encontrou as postagens problemáticas?
Eu acho que o código que faz a verificação está aqui:
Então eu acho que isto:
prefix = @migrate_to_multisite ? "uploads/#{@current_db}/original/" : "original/"
base_url = File.join(SiteSetting.Upload.s3_base_url, prefix)
bad = Upload.by_users.where("url NOT LIKE '#{base_url}%'")
E para garantir
good = Upload.by_users.where("url LIKE '#{base_url}%'")
Me avise se isso funciona para você e eu verei como criar um tópico.
discourse(prod)> prefix = @migrate_to_multisite ? “uploads/#{RailsMultisite::ConnectionManagement.current_db}/original/” : “original/”
discourse(prod)> base_url = File.join(SiteSetting.Upload.s3_base_url, prefix)
discourse(prod)> bad_uploads = Upload.by_users.where(“url NOT LIKE ‘#{base_url}%’”)
discourse(prod)> bad_uploads.count
=> 0
Esta verificação me deu 0 erros
Você fez isso no servidor original? Ou você precisa fazer isso depois que o banco de dados for restaurado, antes que ele faça essa verificação, usando a chave --pause?
Eu fiz no servidor antigo.
Ao restaurar, obtive o mesmo erro
\[2026-01-16 13:45:52\] EXCEPTION: 3 publicações não foram remapeadas para o novo URL de upload do S3. A migração do S3 falhou para o banco de dados ‘default’.
\[2026-01-16 13:45:52\] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log’
Bem. Droga. Não sei mais o que te dizer.
O good encontrou seus uploads?
Eu provavelmente usaria a opção --pause e pararia a restauração antes que ela fizesse essa verificação.
Eu faria o que o Richard disse.
Não tenho certeza sobre sua situação exata, mas você pode simplesmente querer desativar os uploads do S3, fazer o backup, restaurar e ativá-lo novamente. Isso me salvou muitas vezes.
Então, eu tenho que desligar estas opções, correto?
Correto.
- desmarque “habilitar uploads s3”
- backup / download
- upload / restore
- marque “habilitar uploads s3”
Eu não falo italiano quando não é sobre comida… talvez você possa nos fazer um favor e copiar/colar no Google Tradutor 
Desculpe
Habilitar uploads do S3
Armazena uploads no espaço em disco do Amazon S3. IMPORTANTE: requer que credenciais S3 válidas sejam fornecidas (tanto a chave de acesso ID quanto a chave de acesso secreta).
Você não pode habilitar os uploads do S3 porque eles já estão habilitados globalmente, e habilitar os uploads do S3 no nível do site pode causar problemas críticos com os uploads.
Presumo que você já o fez no app.yml então.
Os (novos) uploads estão funcionando corretamente? Se sim, então não há problema.
Em app.yml eu tenho s3 configurado, correto.
Então, o que eu tenho que fazer para fazer backup e restaurar com segurança sem verificar os uploads?
Simplesmente desmarcar “enable s3 uploads” não funciona