공동 관리자가 이메일로 받은 백업 파일을 다운로드할 수 없다고 말했습니다. 다운로드가 약 50% 지점에서 충돌했기 때문이죠.
저도 시도해 보니 동일한 현상이 발생했습니다. 아카이브 다운로드가 정상적으로 진행되다가 “실패 - 네트워크 오류” 메시지와 함께 중단됩니다.
크롬에서 재개를 시도하면 "실패 - 알 수 없는 서버 오류"가 반환됩니다. 지난번에 이 서버에서 백업을 다운로드했을 때(몇 달 전)에는 문제가 없었습니다. (이것은 예상되는 현상입니다)
아무런 생각이 있으신가요?
수정, 추가 정보:
재현 단계:
안녕하세요,
저는 Canapin의 공동 관리자입니다 
Chrome에서 재시도를 하면 "실패 - 알 수 없는 서버 오류"가 표시됩니다. 이 서버에서 백업을 다운로드한 마지막에는 문제가 없었습니다 (몇 달 전).
일회용 링크 때문에 이런 문제가 발생하는지 궁금합니다. 하나의 링크로는 백업을 두 번 다운로드할 수 없습니다. 따라서 한 번 실패하면, 다운로드 재시도가 Discourse 자체에 의해 취소될 가능성이 높습니다.
백업 다운로드 방식을 변경해야 할 것 같습니다.
음, 백업을 다운로드하는 다른 방법도 분명히 있지만, 원인을 파악해서 이 특정 문제를 해결하는 쪽이 더 나을 것 같아 
아마도 이 문제일 수 있지만, 웹 브라우저를 통한 백업 전체 다운로드를 방해하는 유일한 문제는 아닙니다.
업데이트 사항으로, 포럼은 (무관한 이유로) 다른 서버로 마이그레이션되었지만, 문제는 여전히 지속되고 있습니다. 백업 다운로드(3.3GB)가 항상 실패합니다.
다른 포럼에서 백업 파일을 다운로드해 보았지만 동일한 문제가 발생했습니다.
누군가 자신의 인스턴스에서 재현해 볼 수 있을까요? 두 사이트 모두에서 다운로드가 30초 후에 실패합니다.
이 문제는 저만의 문제가 아닐 것 같아 Contribute > Bug 채널로 이동합니다.
1주일 넘게 같은 문제를 겪고 있습니다. 그 기간 동안 두 번 완전히 업데이트했지만, 문제는 여전히 지속되고 있습니다. IONOS에서 자체 호스팅을 하고 있으며, 백업 파일 크기는 1.5GB입니다.
다운로드 중 발생하는 중간 단절(“Failed – Network error”)을 방지하기 위해 /admin/backups/ 경로에 대해 Nginx 타임아웃을 구체적으로 늘리는 방식으로 이 문제를 해결하기 위한 PR을 제출했습니다:
방금 다시 시도해 보았습니다. 여전히 1GB에서 실패합니다.
이것은 너무 위험합니다. 의도하지 않은 서비스 거부(DOS) 위험을 초래할 수 있습니다.
해당 부분에서는 sendfile을 사용하고, nginx가 프록시 없이 이를 처리하도록 해야 합니다.
2025.12.0-latest 버전으로 완전히 업데이트했지만 문제가 여전히 지속됩니다.
수정: WinSCP 같은 도구를 사용하면 백업 파일을 다운로드할 수는 있지만, 홍보된 대로 이메일 링크를 통해 브라우저에서 다운로드가 성공적으로 완료되면 좋겠습니다.
AI의 조언이 틀렸을 수도 있지만, 이 문제를 해결하려면 DISCOURSE_NGINX_PROXY_READ_TIMEOUT: 600 값을 늘리라고 권장하고 있습니다.
나도 같은 현상이 발생하고 있습니다. 백업 파일 크기가 13GB네요. (누가 불평하기 전에 모든 미디어를 S3로 오프로딩하기 전 마지막 전체 백업입니다!)
와! 이 정도 크기는 웹 브라우저가 아니라 SSH를 통해 진행하는 것이 맞을 것 같아요.
어떤 것이 올바른 방법인지에 관계없이, 유용한 내장 기능이 현재 깨져 있다는 사실을 강조하는 것입니다
조금 장난스럽게 말한 거예요.
다만 secure-media를 활성화하면 아래 Python 스크립트는 계속 작동하지 않을 거예요.
백업 파일을 클라이언트로 다운로드하려는 경우를 대비해, 관리자 파일 위치를 알려주는 유용한 텍스트를 추가하는 건 어떨까요?
@Ethsim2님의 이전 게시물을 보지 못했다면 찾지 못했을 것 같습니다.
/var/discourse/shared/standalone/backups/default/your_backup_filename.tar.gz
알 수 없습니다. 알 수도 없습니다. yml 파일의 도커 설정에 따라 다릅니다. 보통 standalone에 있지만, web_only에 있을 수도 있고, 파일 시스템의 어디에 있을 수도 있습니다.
기술적으로는 맞지만, 지난 10년 동안 다른 사람들이 그 같은 우려를 표명한 기억이 없습니다. 매우 오해의 소지가 있다고 생각하시나요? 도움이 될 거라고 생각하시면 자신의 사이트에서 직접 변경할 수 있습니다.
