Discourse는 확장성과 신뢰성을 위해 미디어 업로드를 Amazon S3에 저장할 수 있는 기능을 제공합니다. 그러나 기본적으로 이러한 업로드는 백업에 포함되지 않습니다.
이 가이드에서는 S3 업로드를 백업에 포함하도록 숨겨진 설정을 활성화하는 방법을 다루며, Rails 콘솔 또는 app.yml 파일을 통해 설정을 구성하는 옵션을 제공합니다.
Rails 콘솔을 통해 S3 업로드가 백업에 포함되도록 활성화하려면 다음 단계를 따르세요:
SSH를 통해 Discourse 서버에 액세스합니다.
다음을 실행하여 Discourse Docker 컨테이너에 진입합니다:
cd /var/discourse
./launcher enter app
Rails 콘솔을 시작합니다:
rails c
다음을 실행하여 설정을 활성화합니다:
SiteSetting.include_s3_uploads_in_backups = true
콘솔과 컨테이너에서 나옵니다:
exit
exit
이 변경 사항은 즉시 적용됩니다. 추가 작업은 필요하지 않습니다.
env: 섹션에서 app.yml 파일을 수정하여 이 변경 사항을 적용할 수도 있습니다.
Discourse 앱 컨테이너 디렉토리에 액세스합니다:
cd /var/discourse
containers에 위치한 app.yml 파일을 엽니다:
nano containers/app.yml
env: 섹션 아래에 다음 줄을 추가합니다:
DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true
파일을 저장하고 편집기를 나옵니다.
앱을 다시 빌드하여 변경 사항을 적용합니다:
./launcher rebuild app
이 변경 사항을 적용하려면 설정이 적용되도록 ./launcher rebuild app 명령을 실행해야 합니다.
10개의 좋아요
pfaffman
8월 25, 2023, 12:57오전
2
컨테이너를 삭제하고 다시 시작하는 것만으로도 충분하지 않나요?
1개의 좋아요
삭제할 필요 없이 재시작만으로도 충분할 것 같습니다. 나중에 확인해 보겠습니다.
어쨌든, @pfaffman 님, 이 가이드를 템플릿으로 사용했던 다른 howto 가이드 에 감사드립니다.
2개의 좋아요
pfaffman
8월 25, 2023, 1:12오전
4
컨테이너에 적용된 환경 변수를 변경하려면 반드시 파괴 후 재시작해야 한다고 확신합니다.
물론 Docker Manager로 업그레이드를 수행했다면 컨테이너가 파괴될 때 그 변경 사항이 사라지므로, 재구축(rebuild)이 가장 안전한 권장 사항입니다. 가장 실수하기 어렵고 확실한 방법인 재구축을 권장하는 것이 가장 좋을 것 같습니다.
3개의 좋아요
Bathinda
8월 16, 2024, 2:15오후
9
왜 이 설정 만으로도 백업에 모든 업로드를 포함할 수 있는데:
pfaffman
8월 16, 2024, 2:18오후
10
이것은 로컬 업로드된 파일은 포함하지만, 백업에 포함할 목적으로 s3에 있는 파일을 다운로드하지는 않습니다.
1개의 좋아요
Bathinda
8월 16, 2024, 2:24오후
11
알겠습니다. 몰랐습니다.
하지만 'Local Uploads’와 S3의 ‘Uploads’ 폴더에 저장된 파일(Files Stored in S3 ‘Uploads’ folder)의 차이점이 무엇인가요?
또한, 위에서 안내해 주신 대로 web_only 또는 rails console의 설정은 아직 변경하지 않았습니다. 다만 여기 에서 안내해 준 설정 하나만 선택했을 뿐입니다.
그런데 10분 전에 백업을 실행했을 때 수천 개의 파일을 다운로드한 것처럼 표시되었습니다. (이 파일들은 제 AWS S3 스토리지 버킷에만 있을 것이라고 추정하고, 'Download’라는 단어 자체가 원격 S3 버킷 폴더에서 다운로드한다는 의미라고 생각합니다.)
또한 수많은 파일에 대해 Failed to download(다운로드 실패)라고 표시되고 있습니다. 그래서 저는 이렇게 생각했습니다. 만약 이 파일들이 로컬 클라우드 서버에 있었다면, 왜 백업에 해당 파일들을 포함하지 못했을까요? 아래 스크린샷을 확인해 주세요:
pfaffman
8월 16, 2024, 2:44오후
12
Configure an S3 compatible object storage provider for uploads 를 설정하고 로컬 업로드를 S3로 이동했다면, 업로드된 파일들은 S3에 저장되어 있습니다. S3는 백업되어 있다고 가정하며, 파일을 다운로드하는 것은 비용이 많이 들고 일반적으로 불필요하기 때문에 백업 대상이 아닙니다.
S3에서 파일을 가져와야 하는 경우(예: discourse.org에서 호스팅되고 있으며 다른 호스팅으로 이전하는 경우)에는 S3에 저장된 파일이 포함된 백업이 필요합니다.
왜 S3에서 파일을 다운로드하려고 하나요?
네, S3에서 파일을 다운로드하는 데 실패하는 것으로 보입니다. 제 추측으로는 아무것도 다운로드하지 못했을 가능성이 높지만, 디스크 공간이 가득 차서 그런 것일 수도 있습니다(디스크 가득 참 오류가 발생할 것 같지만, 아닐 수도 있으니).
1개의 좋아요
Bathinda
8월 16, 2024, 2:54오후
13
감사합니다. 다시 한번.
Jay Pfaffman:
왜 S3에서 파일을 다운로드하려고 하나요?
제 사이트가 매우 매우 작은 규모라, 매달 소액이지만 작은 업데이트 때문에 매달 계속 오르는 AWS S3 저장소 비용을 지불하는 것이 다소 비실용적으로 느껴집니다. ‘업로드’ 폴더(그리고 어쩌면 ‘백업’ 폴더 위치도)를 Google One Drive, iDrive, Hetzner 등 저렴한 대안 서비스로 이전할 계획입니다.
이제 보니, AWS의 다양한 저장소 유형(가장 활동적인 것부터 아카이브용 저장소까지)을 처음에 현명하게 선택했다면, 동일한 양/파일 수에 대해 절반의 비용만 들었을 것이라는 것을 깨달았습니다.
하지만 이제 그렇게 하겠습니다.
1개의 좋아요
Bathinda
8월 17, 2024, 6:18오전
14
몇 년 전 미디어 '업로드’를 AWS S3 버킷에 저장하도록 선택했을 때, 그때(제가 확신하는 한) 사용자가 업로드한 기존 미디어도 모두 S3로 이동했습니다.
또한, /var/discourse/shared/web_only/uploads/default/optimized/1X 폴더를 지금 다시 확인해 보니 png 파일이 단 63개뿐이고, /var/discourse/shared/web_only/uploads/default/original/1X에는 단 3개뿐입니다. (‘uploads’ 또는 ‘default’ 폴더에는 1X 외에 유사한 다른 폴더가 존재하지 않습니다.)
또한, 저는 아직 rails 콘솔이나 Yml 파일에서 어떤 옵션도 변경하지 않아서 S3 업로드를 백업에 포함하도록 설정하지 않았습니다. 그런데 왜 S3에서 그렇게 많은 '미디어 업로드’를 다운로드했다고 표시하는 것일까요?!여기에 스크린샷 을 첨부합니다.
게다가, 제 S3 업로드 폴더는 약 3GB(32k 파일)인데, 백업 로그에는 약 3.2k(전체의 10%)만 다운로드했다고 표시되어 있습니다.
매우 혼란스럽습니다.
AWS S3로 전환했던 몇 년 전, 그 옵션이 켜져 있지 않았는지 재확인하기 위해 다른 rails 명령어가 있을까요?
어떤 설명이든 도움이 될 것입니다.
hipp0
1월 12, 2026, 10:18오전
15
백업용 버킷과 업로드용 버킷이 각각 하나씩 있는 경우, 업로드를 포함해야 하나요?
1개의 좋아요
이 가이드는 Discourse에서 숨겨진 설정을 활성화하여 Amazon S3(Simple Storage Service) 업로드를 백업에 포함하는 방법을 설명합니다.
