이런 문제의 근본 원인을 파악하는 데 도움이 필요하시면 말씀해 주세요. 기꺼이 도와드리겠습니다.
2.2GB 백업을 복원하려고 했는데 다음과 같은 오류가 발생하여 복원이 실패했습니다:
EXCEPTION: 44개의 게시물이 새로운 S3 업로드 URL로 재매핑되지 않았습니다. ‘default’ DB의 S3 마이그레이션이 실패했습니다.
현재 사용 중인 버전은 2.6b6으로 비교적 최신 버전입니다. 사이트는 2016년에 만들어진 오래된 사이트입니다.
가끔 여러 가지 이유로 S3로의 자동 재매핑 및 마이그레이션이 실패하는 백업에 부딪히기도 합니다.
오래된 토픽이지만, 수정을 위한 추천 사항이 있을까요? 실제로 복원에 사용할 수 없는 백업이 있다는 것이 조금 불안합니다.
수정: 이 문제가 같은 문제인 것 같아 잘못된 스레드에 글을 남긴 것 같다는 것을 방금 깨달았습니다.
다시 시도해 봤지만 여전히 _44개의 게시물이 재매핑되지 않았습니다_라는 오류에서 복원 실패가 반복되고 있습니다.
백업 전에 S3 업로드를 일시적으로 비활성화하는 방법(@RGJ가 제안한 방식)으로는 문제가 해결되지 않으며, 현재 제대로 작동하는 백업 구성이 전혀 없는 상태라 상당히 심각한 상황입니다.
어떤 방법을 시도해 볼 수 있을까요? 조언을 부탁드립니다.
음, 지금까지 본 사례 중 가장 기이한 경우입니다. 이 게시물을 우연히 발견하게 되었습니다.
https://meta.discourse.org/t/using-object-storage-for-uploads-s3-clones/148916/160?u=ljpp
이미 이 문제로 몇 시간을 허비한 후, 제 사이트에서 사용하지 않는 기능인 DISCOURSE_CDN_URL을 그저 재미로 정의해 보았습니다. 그랬더니 백업이 성공적으로 복원되었습니다.
이 시나리오에서 이 파라미터의 의미는 무엇일까요? @Falco @pfaffman
수정:
말을 거두겠습니다. 테스트가 성공한 후, 프로덕션에서 새로운 백업을 가져와 새 서버로 마이그레이션을 다시 시작했습니다. 하지만 다시 실패했고, 에러 메시지가 변경되었습니다.
EXCEPTION: rake posts:missing_uploads identified 3 issues. S3 migration failed for db ‘default’.
수정2:
그래서 데이터베이스를 계속 파고들다 보니 이 3개의 게시물을 찾았습니다.
- 2개는 매우 오래된 이미지로, 처음 게시되었으나 나중에 모더레이터가 수정된 버전의 이미지로 교체한 것이었습니다. 이 게시물들은 2016년과 2018년 것이었습니다.
- 하지만 마지막 1개는 이상했습니다. 제가 몇 주 전에 작성한 매우 최근의 게시물로, 더 이상 존재하지 않는 개발 서버를 가리키는 oneboxed https:// 링크가 포함되어 있었습니다. 즉, 깨진 링크가 복원 과정을 방해하고 있었던 것입니다.
저는 이 게시물들을 수동으로 삭제했습니다.
이제, 다시 테스트를 돌려보니 백업이 실제로 성공할 수도 있다는 결과가 나왔습니다. 지켜보겠습니다.
@ljpp 저는 복원 실행 시 다음과 같은 오류가 발생하여 비슷한 상황에 처해 있습니다.
EXCEPTION: 1 posts are not remapped to new S3 upload URL. S3 migration failed for db ‘default’.
문제가 되는 게시물을 어떻게 찾아서 삭제하셨는지, 어떤 명령어를 사용하셨는지 자세히 설명해 주실 수 있을까요?
그는 해당 게시글을 삭제했습니다.
하지만 설치를 초기화했으니 그렇게 할 수 없겠죠?
저도 db 복원 시 이 문제가 발생하고 있습니다. 문제 있는 게시물들을 어떻게 찾으셨나요?
해당 체크를 수행하는 코드는 여기 있는 것 같습니다:
따라서 이 코드라고 생각합니다:
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}%'")
그리고 확실하게 하려면
good = Upload.by_users.where("url LIKE '#{base_url}%'")
이 방식이 본인에게 잘 작동하는지 알려주시면, 관련 주제를 만들어보겠습니다.
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
이 체크를 수행했을 때 오류가 0건으로 나타났습니다
원래 서버에서 그 작업을 수행하셨나요? 아니면 데이터베이스가 복원된 후, 해당 체크가 실행되기 전에 --pause 스위치를 사용하여 수행해야 하나요?
구 서버에서는 그렇게 했습니다.
복원했을 때 동일한 오류가 발생했습니다
[2026-01-16 13:45:52] 예외: 3개의 게시물이 새 S3 업로드 URL로 다시 매핑되지 않았습니다. db 'default’에 대한 S3 마이그레이션이 실패했습니다.
[2026-01-16 13:45:52] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log’
글쎄요. 아쉽네요. 더 드릴 말씀이 딱히 없습니다.
good 명령이 업로드된 파일들을 찾았나요?
--pause 스위치를 사용해서 해당 체크가 실행되기 전에 복원 과정을 중지하는 것이 좋겠습니다.
Richard가 말한 대로 하시는 것이 좋습니다.
사용자의 정확한 상황을 정확히 알 수는 없지만, 아마도 단순히 S3 업로드를 끄고, 백업을 만든 후 복원하고, 다시 켜는 것만으로 충분할 수 있습니다. 이 방법이 여러 번 큰 도움이 되었습니다.
그러니까 이 옵션들을 꺼야 한다는 거죠?
맞습니다.
- “S3 업로드 활성화” 선택 해제
- 백업 / 다운로드
- 업로드 / 복원
- “S3 업로드 활성화” 선택
음식이 아닌 주제에 대해서는 이탈리아어를 못 해요… 우리 모두를 위해 구글 번역기에 복사/붙여넣기해 주실 수 있나요? 
죄송합니다
S3 업로드 활성화
업로드된 파일을 Amazon S3 디스크 공간에 저장합니다. 중요: 유효한 S3 자격 증명이 제공되어야 합니다(액세스 키 ID와 액세스 키 시크릿 모두).
이미 전역적으로 S3 업로드가 활성화되어 있어 사이트 수준에서 S3 업로드를 활성화하면 업로드에 중대한 문제가 발생할 수 있으므로 활성화할 수 없습니다.
이미 app.yml에서 그렇게 처리하셨을 것 같습니다.
(새로운) 업로드가 정상적으로 작동하나요? 그렇다면 문제가 없는 것입니다.
app.yml에서 s3를 올바르게 구성했습니다.
그렇다면 업로드를 확인하지 않고 안전하게 백업 및 복원하려면 무엇을 해야 하나요?
단순히 “s3 업로드 활성화”를 해제하는 것은 작동하지 않습니다.