S3 (não AWS) parou de funcionar aleatoriamente, presumivelmente desde uma atualização

Suporte
1

Tenho um bucket configurado, mas parece que ele está tentando usar o padrão?

Eu uso o GarageHQ como uma alternativa leve ao MinIO.

Estou na versão 3.6.0.beta1-dev
( ed6beea336 )

[2025-09-14 10:40:34] Removendo o diretório tmp ‘/var/www/discourse/tmp/backups/default/2025-09-14-104012’…
[2025-09-14 10:40:34] Enviando arquivo compactado…
[2025-09-14 10:40:35] EXCEPTION: Bucket not found: default

[2025-09-14 10:40:35] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/dualstack.rb:21:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/accelerate.rb:43:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/checksum_algorithm.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:16:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/invocation_id.rb:16:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/seahorse/client/plugins/request_callback.rb:89:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/seahorse/client/plugins/response_target.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/telemetry.rb:39:in `block in call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/telemetry/no_op.rb:29:in `in_span'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/telemetry.rb:53:in `span_wrapper'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/telemetry.rb:39:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/seahorse/client/request.rb:72:in `send_request'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/client.rb:3710:in `create_multipart_upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/multipart_file_uploader.rb:67:in `initiate_upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/multipart_file_uploader.rb:58:in `upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/file_uploader.rb:42:in `block in upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/user_agent.rb:90:in `metric'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/file_uploader.rb:40:in `upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/customizations/object.rb:477:in `block in upload_file'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/user_agent.rb:90:in `metric'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/customizations/object.rb:476:in `upload_file'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:48:in `upload_file'
/var/www/discourse/lib/backup_restore/backuper.rb:351:in `upload_archive'
/var/www/discourse/lib/backup_restore/backuper.rb:41:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:9:in `backup'
/var/www/discourse/script/spawn_backup_restore.rb:31:in `block in <main>'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>'

O último backup foi ontem, mas agora não está mais funcionando. Outros serviços ainda conseguem fazer backup no meu S3 local sem problemas.

Alguém sabe como posso consertar isso?

2

Sim. A AWS quebrou a biblioteca S3 para muitos outros serviços.

Can't rebuild due to AWS SDK gem bump and new AWS Data Integrity Protections tem algumas soluções alternativas.

Eu criei este aws-revert-template.yml para reverter para uma versão mais antiga. Não sei se ainda funciona; meu arquivo é datado 2025-08-06T05:00:00Z

3

Hmm, não estou totalmente convencido de que este seja o problema, embora

image
image917×583 24.7 KB

a menos que eu esteja enganado, eu estava na versão 3.6 por mais de 2 dias, e ainda assim recebi um backup há 2 dias e 10 dias atrás.

4

Não muito mais. Acho que você está enganado.

Aqui está o commit em que você está:

image
image268×122 6.42 KB

Mas também:

Seu bucket se chama “default”?

5

Sim, estou no commit agora, inicialmente não estava quando postei este problema, atualizei para descartar um bug

6

não, como afirmado no OP, é por isso que não acredito que seja o mesmo problema a que você está se referindo, meu bucket é especificado, tentei tanto nas configurações da UI da seção de backup quanto via variáveis de ambiente no yaml, ele ainda tenta usar o padrão, independentemente

para esclarecer, nada mudou no lado do discourse ou do garage desde que parou de funcionar, exceto por uma atualização para 3.5 e depois para 3.6

1 curtida
7

talvez alguém com S3 real possa verificar se ele está selecionando corretamente um bucket? o mesmo para outros terceiros como backblaze, r2 etc?

8

Então eu criei um bucket chamado “Default” e ele funciona como pretendido, então sim, ele não está pegando corretamente o nome do bucket que eu digo.

9

Exceto que milhares de pessoas e a hospedagem CDCK também seriam provavelmente afetadas e não estão. É muito mais provável que você tenha excluído ou adicionado um caractere a uma linha em seu app.yml.

Você pode fazer coisas como esta:

grep -i S3 /var/discourse/containers/*

docker exec -it app bash -c 'grep s3 /var/www/discourse/config/discourse.conf

E se você configurou o s3 nas configurações em vez de com variáveis de ambiente, então você pode dar uma olhada em Configurar um provedor de armazenamento de objetos compatível com S3 para uploads para ver como eles se parecem.

10

não há nada de errado com minha configuração, nada foi alterado exceto a atualização do discourse. Tentei a configuração no yaml e a configuração na UI, as configurações da UI literalmente a mostram como “cyanlabs-community” e, no entanto, o backup ainda tenta salvar em “default”

Screenshot_2025-09-18-21-47-29-55_3aea4af51f236e4932235fdada7d1643
Screenshot_2025-09-18-21-47-29-55_3aea4af51f236e4932235fdada7d16431115×259 74.2 KB

apesar de ter o s3 configurado na UI, o arquivo discourse.conf não contém nenhuma referência s3 conforme seu segundo comando

Screenshot_2025-09-18-21-57-49-03_3aea4af51f236e4932235fdada7d1643
Screenshot_2025-09-18-21-57-49-03_3aea4af51f236e4932235fdada7d16431637×447 76.9 KB

11

Isso, no entanto, significa que o bucket não existe. Você pode tentar criar um bucket e credenciais totalmente novos e ver se o upload funciona lá?

1 curtida
12

Obrigado, mas sinto que estou dando voltas em círculos aqui.

O bucket padrão não existia no início desta conversa, eu o criei desde então e ele usa esse bucket, apesar de ter o bucket cyanlabs-community definido nas configurações.

Ambos cyanlabs-community e default existem na instância s3, mas o Discourse não usará cyanlabs-community não importa o que eu tente.

Novo bucket cyanlabsdiscourse

image
image822×106 10.2 KB

Resultado do backup

[2025-09-22 15:14:59] Finalizando backup...
[2025-09-22 15:14:59] Finalizando arquivo de dump do banco de dados: cyanlabs-official-community-2025-09-22-151437-v20250916082012.sql.gz
[2025-09-22 15:14:59] Removendo o diretório temporário '/var/www/discourse/tmp/backups/default/2025-09-22-151437'...
[2025-09-22 15:14:59] Enviando arquivo compactado...
[2025-09-22 15:15:37] Executando o hook after_create_hook para o backup...
[2025-09-22 15:15:37] Deletando backups antigos...
[2025-09-22 15:15:37] Limpando coisas...
[2025-09-22 15:15:37] Removendo arquivo compactado do armazenamento local...
[2025-09-22 15:15:37] Removendo sobras de '.tar'...
[2025-09-22 15:15:37] Marcando backup como concluído...
[2025-09-22 15:15:37] Atualizando estatísticas do disco...
[2025-09-22 15:15:37] Notificando 'CyanLabs' sobre o fim do backup...
[2025-09-22 15:15:40] Concluído!

bucket cyanlabsdiscourse

image
image1122×661 12 KB

bucket default

image
image1049×543 23.5 KB

O interessante é que ele ainda tenta fazer a conexão em bucketname.s3.domain.tld, por exemplo, cyanlabsdiscourse.s3.domain.tld, pois sem adicionar um registro DNS, não funcionaria nesse sub subdomínio. então a configuração está sendo honrada para a URL, mas parece ser ignorada pela seleção do bucket.

13

Eu sinto que tentei de tudo, por enquanto vou usar o bucket padrão, eu acho.

14

A AWS pode ser misteriosa! Sinto muito que você não tenha conseguido usar o nome de bucket preferido. É difícil ajudar sem poder replicar, então acho que você terá que se contentar em usar o padrão como nome do bucket.