내장된 백업 기능을 사용하여 마이그레이션을 시도하면 압축 과정에서 디스크가 빠르게 가득 차는 문제가 발생합니다. 아직 약 60GB의 여유 공간이 있었지만, 백업 중 디스크가 가득 차면서 실패합니다.
그러나 /var/discourse 폴더 전체를 수동으로 압축하면 아카이브 크기는 약 30GB에 불과합니다(폴더 자체의 크기는 약 34GB).
용량이 가득 차면 즉시 해제되므로, 80% 시점에 스크린샷을 촬영했습니다.
따라서 제 질문은 다음과 같습니다:
• /var/discourse 폴더 전체를 단순히 tar/압축하여 새 서버로 이동하고, 압축을 푼 후 Discourse를 실행할 수 있나요?
• 아니면 권장하는 방법(데이터베이스 백업 + 업로드 파일 별도 복사)을 따르는 것이 필수인가요?
• 백업 압축 과정에서 디스크가 가득 차는 것을 방지할 방법이 있나요?
안녕하세요,
아래 링크를 확인해 보세요:
네, 여유 공간이 더 있으면 됩니다 
이런 뻔한 답변을 제외하면, 백업 생성 시 더 많은 공간을 차지하지 않도록 하는 기능 요청이 몇 가지 있습니다만, 아직까지 반영되지 않았습니다: Reduce local disk space needs by not (redundantly) gzipping backups & Add option to disable backup compression
또한,
./launcher cleanup
을 실행하지 않았다면, 공간을 차지하는 Docker 이미지들이 여러 개 있을 수 있습니다.
docker system prune가 도움이 될 것 같습니다
44GB로 해방(확장)을 시도했는데, 서버 전체 용량은 98GB입니다. 그런 다음 S3를 다시 시작했지만 여전히 작동하지 않습니다. 공간이 부족하다는 메시지가 뜨고, 백업이 왜 그렇게 큰지에 대해 Discourse에서 뭐라고 했는지 모르겠습니다.
[2025-08-20 10:11:31] Finalizing backup…
[2025-08-20 10:11:31] Creating archive: discourse-2025-08-20-101058-v20250812033430.tar.gz
[2025-08-20 10:11:31] Making sure archive does not already exist…
[2025-08-20 10:11:31] Creating empty archive…
[2025-08-20 10:11:31] Archiving data dump…
[2025-08-20 10:11:31] Archiving uploads…
[2025-08-20 10:16:35] Removing tmp ‘/var/www/discourse/tmp/backups/default/2025-08-20-101058’ directory…
[2025-08-20 10:16:36] Gzipping archive, this may take a while…
[2025-08-20 10:28:05] EXCEPTION: gzip -1 /var/www/discourse/public/backups/default/discourse-2025-08-20-101058-v20250812033430.tar
Failed to gzip archive.
gzip: /var/www/discourse/public/backups/default/discourse-2025-08-20-101058-v20250812033430.tar.gz: No space left on device
[2025-08-20 10:28:05] /var/www/discourse/lib/discourse.rb:171:in `execute_command’
/var/www/discourse/lib/discourse.rb:137:in `exec’
/var/www/discourse/lib/discourse.rb:32:in `execute_command’
/var/www/discourse/lib/backup_restore/backuper.rb:253:in `create_archive’
/var/www/discourse/lib/backup_restore/backuper.rb:40: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 ’
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork’
/var/www/discourse/script/spawn_backup_restore.rb:4:in `’
[2025-08-20 10:28:05] Deleting old backups…
[2025-08-20 10:28:06] Cleaning stuff up…
[2025-08-20 10:28:06] Removing ‘.tar’ leftovers…
[2025-08-20 10:28:07] Marking backup as finished…
[2025-08-20 10:28:07] Notifying ‘VegaMonika’ of the end of the backup…
/var/discourse/shared/standalone/backups/default에 남아 있는 .tar 파일을 삭제해야 할 것 같습니다.
백업에 담을 수 있는 용량보다 업로드된 파일이 더 많은 것 같습니다. (1) 더 큰 디스크를 확보하거나, (2) 자산을 Spaces 또는 S3로 이동하거나, (3) 업로드를 볼륨으로 이동하거나, (4) 업로드를 백업하지 않는 방식으로 해결해야 합니다.
가장 간단한 즉각적인 해결책은 .tar 파일을 삭제한 후 업로드를 백업하지 않는 것입니다.
EC2 인스턴스를 더 큰 인스턴스로 이전하는 과정에서 이 방법의 변형 버전을 사용해 본 적이 있습니다. 다만, 새 서버가 기존 서버와 동일한 기본 OS 이미지, 호스트명, 설치된 소프트웨어 및 IP 주소를 사용한다는 전제 하였습니다. /var/discourse를 새 서버로 옮긴 후 launcher rebuild app 명령을 실행하자 사이트가 바로 정상적으로 실행되었습니다.
따라서 이러한 매우 구체적인 상황에서는 제가 시도해 본 한 번의 경험에서 아주 잘 작동했습니다.
이동 방식이 다소 번거롭긴 하지만, 기본 설치 환경이고 먼저 모든 Docker 컨테이너를 중지했는지 확인했다면, 아마 잘 작동할 것입니다.
snap remove aws-cli
.\launcher stop app
docker system prune
apt autoremove
.\launcher enter app
discourse backup
docker cp “app:/var/www/discourse/public/backups/default/your-site-2006-01-02-150405-v20200101150405.tar.gz “ “root@[server_ip_address]:/var/discourse/shared/standalone/backups/default/your-site-2006-01-02-150405-v20200101150405.tar.gz“
exit
snap install aws-cli --classic
aws configure
aws s3 cp “/var/discourse/shared/standalone/backups/default/your-site-2006-01-02-150405-v20200101150405.tar.gz“ “myBucket://your-site-2006-01-02-150405-v20200101150405.tar.gz“
aws s3 cp “/var/discourse/containers/app.yml“ “myBucket://app.yml“