다운로드가 엄밀히 필수적이지는 않을 거라고 봅니다. 대부분의 사용자는 단일 클라우드 인스턴스를 실행하고 있으며, 백업용 S3 버킷이 있기도 하고 없을 수도 있습니다. 제가 언급했듯이, 이 사용자 그룹이 오프사이트 백업을 만들 수 있는 유일한 방법은 백업을 다운로드하는 것입니다.
저라면 완전히 다른 프로바이더에서 추가적인 백업 시스템까지 구축할 정도입니다. 특히 이 오픈소스 개발자에게 최근 일어난 일이 있은 후로는 더욱 그렇습니다. 그 사건의 타당성을 불문하고, 완전히 별개의 저장소/프로바이더에 주 1회 또는 월 1회 백업을 해두는 것이 훌륭한 경고가 될 수 있습니다.
@pfaffman 이 기능을 추가해 주셔서 감사합니다. 이제 정말로 손쉽게 진행됩니다! (다만, 대규모 백업 복원은 어떤 환경이든 항상 긴장되고 긴 대기 시간이 필요합니다.)
참고로 이 경로는 잘못되었을 것 같습니다: 기본적으로 web-only여야 하지 않나요?:
volumes:
- volume:
host: /var/discourse/shared/web-only
guest: /shared
- volume:
host: /var/discourse/shared/web-only/log/var-log
guest: /var/log
P.S. 이에 따라 원본 게시물(OP)을 수정했습니다.
네. web-only인데, 다른 모든 맥락에서는 web_only로 사용되므로 약간 혼란스럽습니다. 하지만 디렉터리나 컨테이너 같은 것들은 상황이 다를 수도 있겠죠.
무슨 일이길래… SearXNG와 씨름하느라 4시간을 허비했는데, 이건 5분이면 끝날 일이에요 (정말 docker 관련 작업이 싫어요)
수정 및 오프토픽
진짜 
he와 ck가 금지된 단어였나요? 학교에서 비속어가 아닌 단어로 가르쳐줬거든요. 그래서 그들이 틀렸던 거겠죠, 당연하죠 
감시 단어(watched words)가 처음 테스트될 때 추가되었고 이후에 제거되지 않은 것 같습니다.
네. 저도 그 부분에 대해 자주 혼란을 겪습니다. 사실, 단일 컨테이너에서 이중 컨테이너로 전환하기 위해 단순히 이름을 변경하려 했을 때 언더스코어/대시 문제를 잘못 처리해서 실패한 적이 있었던 것 같습니다.
그리고 더糟糕한 것은, 이것이 제 실수라고 꽤 확신합니다. discourse-setup에서 이중 컨테이너 옵션을 만들 때 어떤 오류가 발생했는데(아마도 컨테이너 이름에 언더스코어를 사용할 수 없었던 것 같습니다?) Ruby는 파일명에 언더스코어를 좋아하므로, 그래서 제가 거기에 언더스코어를 사용한 것일까요? 그것이 원인인 것 같습니다. 또한 web_only는 유효한 호스트명이 되어야 하므로 Docker 컨테이너 이름으로 사용할 수 없을 것 같습니다.
디렉터리 경로에는 하이픈을 선호하므로 현재 상태 그대로 두는 것이 좋겠고, 컨테이너 이름에 밑줄을 사용하는 것도 솔직히 말이 되니 이 역시 그대로 두자.
참고로, 두 개의 컨테이너 구성을 사용하는 사람들에게 메타에 제목이나 자체 인증 배지가 있어야 한다고 생각한다 
1년 동안 이곳에 머물렀다면, 표준 설치 환경이 마이그레이션되어야 한다고 생각한다. 
단일 컨테이너 설립에 대한 기존 문서가 그렇게 많지 않다면, 이것이 기본값이 되어야 한다고 거의 주장할 수도 있을 것 같습니다. 다만, 데이터베이스에 주의를 기울여야 할 수 있다는 것을 사용자에게 알리기 위한 어떤 도구화가 필요할 것입니다.
저는 두 개의 컨테이너로 설치하는 것에 대해 불만을 품거나 두려워하는 사람들을 자주 봅니다. (예를 들어, 얼마 전에는 제가 설치를 진행할 때 생성한 2컨테이너 설치를 단일 컨테이너로 옮기기를 원하는 사람이 있었습니다.) 2컨테이너 설치에서 문제가 발생하는 경우는 매우 드물며, 실제로 문제가 되는 유일한 경우에도 Postgres 업그레이드를 준비가 될 때까지 미룰 수 있어 오히려 번거로움을 줄여줍니다. 일반적으로 PG 업그레이드는 상당한 시간 동안 미룰 수 있습니다. (AI 플러그인이 코어에 추가되어 해당 확장이 필요하게 된 경우를 제외하고는요.)
다음 내용 이후로 백업이 실패하기 시작했습니다:
[2025-09-09 09:34:50] Creating archive: blah-forum-2025-09-09-093246-v20250828181952.tar.gz
[2025-09-09 09:34:50] Making sure archive does not already exist...
[2025-09-09 09:34:50] Creating empty archive...
[2025-09-09 09:34:50] EXCEPTION: tar --create --file /var/www/discourse/public/backups/default/blah-forum-2025-09-09-093246-v20250828181952.tar --files-from /dev/null
tar: /var/www/discourse/public/backups/default/blah-forum-2025-09-09-093246-v20250828181952.tar: Cannot open: Permission denied
tar: Error is not recoverable: exiting now
web_only 컨테이너 내에서 권한을 확인해 보니 다음과 같습니다:
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 root root 4096 Sep 6 12:37 default
다른 인스턴스(표준 설치)를 보면 소유자가 다릅니다:
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 discourse www-data 4096 Sep 9 03:46 default
여기서 무엇이 잘못되었고, web_only 컨테이너의 해당 디렉토리에 무엇을 변경해야 할까요? 표준 설치와 동일하게 설정해야 하는가요?
요약하면, 다음을 시도해 보세요.
docker exec -it web_only bash
chown -R discourse:www-data /shared/backups
그리고 더 자세한 설명을 드리자면.
코드를 확인하지 않고 추측하자면, 다음으로 data 컨테이너를 재빌드(rebuild)하는 것을 시도할 것입니다. 무엇이든 변경된 것이 data 컨테이너에도 적용되었거나 영향을 미쳤을 것이라는 희망을 가지고요.
잘못된 조언일 수 있지만, ...backups/default를 전체 사용자(world)가 쓸 수 있게 변경하고 백업의 소유권을 확인해 보는 것도 방법입니다.
따라서 web 컨테이너(백업을 수행하는 컨테이너)에서 default의 소유권을 discourse:www-data로 변경하는 것이 좋을 것 같습니다.
최근의 단일 컨테이너(single-container) 환경은 다음과 같습니다:
root@forum.mbse-capella.org(app):~$ docker exec -it app bash
root@new-app:/# grep www /etc/passwd
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
root@new-app:/# grep discourse /etc/passwd
discourse:x:1000:1000::/home/discourse:/bin/bash
과거에는 빌드 과정에서 모든 파일의 소유권을 chown하는 것이 있었지만, 이 작업은 매우 오랜 시간이 걸릴 수 있어 어느 시점에 제거되었을 것이라고 생각합니다(이것은 커밋을 주의 깊게 관찰한 근거보다는 느낌에 가깝습니다).
이것은 ./launcher enter web_only와 동일한가요?
대부분 그렇습니다. ./launcher는 먼저 git pull을 수행합니다(최소 그렇게 생각했지만, 아닐 수도 있나요?). 그리고 ./launcher보다 docker에서 탭 완성(tab-completion)이 작동할 가능성이 더 높습니다.
또한 이 명령은 루트 디렉터리로 이동시키는 반면, launcher는 discourse 디렉터리로 이동시킵니다.
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 discourse www-data 4096 Sep 6 12:37 default
이것이 올바른 수정인 것 같습니다. 다음 백업에서 어떻게 될지 지켜보겠습니다. 감사합니다!
지금 명령줄이나 UX에서 하나를 실행해서 제대로 작동했는지 확인할 수 있습니다.
또한, 제가 좀 더 똑똑했다면:
docker exec -it web_only bash -c "chown -R discourse:www-data /shared/backups"
인내심을 갖고 예약된 작업이 실행되기를 기다렸는데, 다행히 잘 작동했습니다. 도움을 주셔서 정말 감사합니다, @pfaffman 
이 문제가 다른 사용자에게도 발생할 수 있는지, 그리고 이를 방지하기 위해 어딘가에서 변경이 필요한지 궁금합니다.
우리가 다른 점이 바로 그겁니다.
네. 재빌드(rebuild)할 때마다 실행되던 chown 명령이 있었을 겁니다. 꽤 확신이 있습니다. 이 명령은 시간이 좀 걸리고, 거의 항상 불필요합니다(불필요하지 않을 때는 제외하고요). 이건 컨테이너가 하나인지 두 개인지와는 무관합니다. 베이스 이미지의 Debian 버전이 하나에서 다른 버전으로 변경될 때, 새 버전이 기존 버전과 다른 사용자 매핑(user mappings)을 가지고 있기 때문이라고 생각합니다.
이 환경에서는 docker_manager 플러그인이 유용하지 않나요? - 항상 앱을 다시 빌드하라고 알려주거든요!
"this"가 정확히 무엇을 가리키는지 잘 모르겠지만, 이 주제와 제가 언급한 주제는 모두 표준 설치(Standard install)를 대상으로 하기 때문에 docker_manager는 정상적으로 작동합니다.
docker_manager는 다른 서버로 이전하는 과정과는 무관합니다. 새로운 컨테이너를 구축해야 하니까요.
기본 이미지(base image)에 변경 사항이 있을 때 새로운 앱을 구축하도록 강제해야 하는데, 최근에는 이런 일이 꽤 자주 발생하는 것 같습니다. 솔직히 말해서, 그 안에서 어떤 메커니즘이 작용하는지 아직 완전히 파악하지 못했습니다.
제가 이 문제를 발견한 과정은 다음과 같습니다. web_only로 부트스트랩을 한 후 replace(destroy, start)를 실행했습니다. 그런 다음 플러그인을 하나만 변경하고 업데이트를 시도했는데, 앱 재빌드를 하라는 메시지가 뜨더군요!
./launcher bootstrap data && ./launcher destroy data && ./launcher start data
명령어는 ./launcher stop data로 데이터 컨테이너를 먼저 중지하지 않으면 오류로 실패합니다.
이 문제는 ./discourse-setup --two-container로 새로 생성된 인스턴스에서 더 긴 방식으로 변환된 경우에도 발생합니다.
두 경우 모두
./launcher stop web_only && ./launcher rebuild data && ./launcher rebuild web_only
및
./launcher bootstrap web_only && ./launcher destroy web_only && ./launcher start web_only
은 예상대로 작동합니다.
무엇을 놓치고 있나요?
data_yml error.txt (5.2 KB)
data_yml error --two-container method.txt (5.0 KB)
네, 해당 로그에는 "postgres already running stop container"라는 메시지가 포함되어 있습니다.
이는 데이터 컨테이너를 부트스트랩하기 전에 먼저 컨테이너를 중지해야 한다는 것을 시사합니다.
설치 지침이 더 이상 유효하지 않은 것 같습니다?
이것은 또한 완전한 재빌드 시 더 긴 다운타임이 발생할 수 있음을 의미합니다. 다행히 그런 경우는 드뭅니다.
실제로 데이터 컨테이너를 중지한 후에는 문제가 없으셨을 것 같습니다.