S3(AWS 아님) 백업이 업데이트 이후로 작동하지 않음

버킷은 설정해 두었는데, 기본적으로 설정된 버킷을 사용하려는 것처럼 보입니다.

저는 GarageHQ를 MinIO의 경량 대안으로 사용하고 있습니다.

현재 3.6.0.beta1-dev 버전입니다.
( ed6beea336 )

[2025-09-14 10:40:34] 임시 디렉터리 ‘/var/www/discourse/tmp/backups/default/2025-09-14-104012’ 삭제 중…
[2025-09-14 10:40:34] 아카이브 업로드 중…
[2025-09-14 10:40:35] 예외: 버킷을 찾을 수 없음: 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>'

마지막 백업은 어제까지 정상적으로 수행되었는데, 지금은 더 이상 작동하지 않습니다. 다른 서비스들은 여전히 로컬 S3로 백업하는 데 문제가 없습니다.

이 문제를 해결하는 방법에 대해 아는 분이 있을까요?

네. AWS가 S3 라이브러리를 여러 다른 서비스에서 깨뜨렸어요.

Can't rebuild due to AWS SDK gem bump and new AWS Data Integrity Protections 에 몇 가지 우회 방법이 있습니다.

구버전으로 되돌리기 위해 이 aws-revert-template.yml 파일을 만들었습니다. 지금도 동작하는지 모르겠어요. 제 파일의 날짜는 [date=2025-08-06 timezone=“America/Chicago”]입니다.

음, 그게 문제인지는 확신이 서지 않네요.

제가 틀린 게 아니라면, 3.6 버전을 2일 이상 사용했는데도 백업이 2일 전과 10일 전에 생성되어 있거든요.

그보다 조금 더 오래였을 겁니다. 제가 틀린 것 같습니다.

현재 사용 중인 커밋은 다음과 같습니다:
UX: control event display through a site setting (#34795) · discourse/discourse@ed6beea · GitHub

그리고:

버킷 이름이 "default"인가요?

네, 지금 커밋을 적용한 상태입니다. 이 이슈를 등록했을 때는 아직 적용하지 않았고, 버그를 배제하기 위해 업데이트했습니다. 이슈를 등록했을 당시에는 3.5 버전이었습니다.

아니요, OP(원문)에서 언급했듯이 제가 말씀드린 문제가 그분이 언급하신 문제와 같지 않다고 생각하는 이유입니다. 제 버킷은 명시적으로 지정되어 있으며, 백업 섹션의 UI 설정과 yaml의 환경 변수를 통해 모두 시도해 보았지만, 여전히 default를 사용하려고 합니다.

정리하자면, 작동이 멈춘 이후 discourse나 garage 쪽에서 3.5 버전으로 업데이트하고 그 다음 3.6 버전으로 업데이트한 것 외에는 아무것도 변경되지 않았습니다.

실제로 S3를 사용 중인 누군가가 버킷이 올바르게 선택되는지 확인해 줄 수 있을까요? Backblaze, R2 등 다른 서드파티 서비스들도 마찬가지입니다.

그래서 "default"이라는 이름의 버킷을 만들었는데 의도대로 작동하네요. 즉, 제가 지정한 버킷 이름을 제대로 인식하지 못하고 있는 것이 맞습니다.

따라서 이것은 Discourse의 버그인 것 같습니다.

수천 명의 사용자와 CDCK 호스팅도 영향을 받을 가능성이 높지만, 실제로는 그렇지 않습니다. app.yml 파일의 한 줄에서 문자를 삭제하거나 추가했을 가능성이 훨씬 더 높습니다.

다음과 같은 작업을 수행할 수 있습니다:

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

ENV 변수가 아닌 설정에서 S3를 구성했다면, 업로드용 S3 호환 객체 저장소 제공자 구성을 참고하여 해당 설정이 어떤 모습인지 확인해 볼 수 있습니다.

제 설정에 문제가 있는 건 아니고, discourse 업데이트를 제외하고는 아무것도 변경하지 않았습니다. yaml 설정과 UI 설정을 모두 시도해 보았는데, UI 설정에는 실제로 "cyanlabs-community"로 표시되어 있고, 그럼에도 불구하고 백업은 여전히 "default"로 저장하려고 합니다.

UI에서 s3가 설정되어 있음에도 불구하고, 두 번째 명령에 따르면 discourse.conf 파일에는 s3 관련 항목이 포함되어 있지 않습니다.

이 메시지는 해당 버킷이 존재하지 않음을 의미합니다. 새 버킷과 자격 증명을 새로 생성하여 거기에 업로드가 정상적으로 작동하는지 확인해 보시겠습니까?

감사합니다만, 여기서 계속 같은 문제를 반복하고 있는 것 같습니다.

이 대화가 시작될 때 ‘default’ 버킷은 존재하지 않았고, 이후에 제가 직접 생성했습니다. 설정에 버킷 이름이 cyanlabs-community로 지정되어 있음에도 불구하고, 실제로는 해당 버킷(default)을 사용하고 있습니다.

cyanlabs-communitydefault 두 버킷 모두 S3 인스턴스에 존재하지만, 제가 어떻게 시도해봐도 Discourse는 cyanlabs-community 버킷을 사용하지 않습니다.

새로운 버킷 cyanlabsdiscourse

백업 결과

[2025-09-22 15:14:59] Finalizing backup...
[2025-09-22 15:14:59] Finalizing database dump file: cyanlabs-official-community-2025-09-22-151437-v20250916082012.sql.gz
[2025-09-22 15:14:59] Removing tmp '/var/www/discourse/tmp/backups/default/2025-09-22-151437' directory...
[2025-09-22 15:14:59] Uploading archive...
[2025-09-22 15:15:37] Executing the after_create_hook for the backup...
[2025-09-22 15:15:37] Deleting old backups...
[2025-09-22 15:15:37] Cleaning stuff up...
[2025-09-22 15:15:37] Removing archive from local storage...
[2025-09-22 15:15:37] Removing '.tar' leftovers...
[2025-09-22 15:15:37] Marking backup as finished...
[2025-09-22 15:15:37] Refreshing disk stats...
[2025-09-22 15:15:37] Notifying 'CyanLabs' of the end of the backup...
[2025-09-22 15:15:40] Finished!

cyanlabsdiscourse 버킷

default 버킷

흥미로운 점은 여전히 버킷 이름으로 연결을 시도한다는 것입니다. 예를 들어 cyanlabsdiscourse.s3.domain.tld와 같은 형태로요. DNS 레코드를 추가하지 않으면 해당 서브서브도메인으로 작동할 수 없기 때문입니다. 즉, URL 설정은 잘 반영되고 있지만, 버킷 선택에서는 무시되는 것 같습니다.

모든 방법을 다 써본 것 같은데, 지금은 그냥 기본 버킷을 쓰기로 했어요.

AWS는 신비롭습니다! 원하시는 버킷 이름을 사용할 수 없으셨다니 죄송합니다. 재현이 불가능하니 도움을 드리기 어렵고, 결국 기본값을 버킷 이름으로 사용하셔야 할 것 같습니다.