Move your Discourse Instance to a Different Server

[Discourse]

This is a guide for moving your Discourse instance from one server to another, including all settings and data. This guide applies to self-hosted Discourse instances using Docker.

Required user level: System Administrator

This procedure involves domain and DNS changes. Ensure you have access to both the source and destination servers.

This guide walks you through the process of migrating your Discourse instance from one server to another, ensuring your data, settings, and configuration are preserved.

Disclaimer added by @pfaffman 2025-09-12T05:00:00Z.

These instructions don’t work well now because you’re now using https and let’s encrypt, which require the new server to have DNS pointed to it so that it can request keys. What I recommend is follow the Move a Discourse site to another VPS with rsync (perhaps using --exclude postgres* and then backing up and restoring the database from the command line.) This is slick since if you know how, you can tweak your local DNS to point to the new server so you can test that it works while the rest of the internet still sees the old site.

Summary

You will perform the following key steps in this guide:

1. Back up your current Discourse instance (source server).
2. Transfer the backup file to your target Discourse instance (destination server).
3. Restore the backup on the destination server.
4. Update DNS settings (if applicable).

Adjusting DNS settings (when required)

If you’re using the same domain for the new server, reduce the TTL (time to live) on your DNS entry in advance. This ensures minimal downtime during propagation of the updated DNS records. If you’ll use a new domain, this step can be skipped.

Logging in and preparing the source server

1. Log in to your source Discourse instance with an account that has administrator permissions.
2. Ensure both the source and destination servers are using:
   • The same Discourse version.
   • The same set of plugins.
3. Upgrade the Discourse version on both servers by visiting /admin/upgrade.

Avoid restoring a newer backup onto an older Discourse version, or incompatible PostgreSQL versions, as this may result in errors.

Creating and downloading the backup

1. Navigate to /admin/backups on your source Discourse instance.
2. Click the Backup button to create a backup:
   
   
3. When prompted, confirm by clicking Yes.
4. Once the backup is complete, go to the Backup files tab, and locate the newly created backup.
5. Click Download to receive an email with a download link. Click the link in the email to save the backup file locally.
   
   

Before proceeding, review your app.yml file to ensure any optional settings, such as CDN configurations, installed plugins, or HTTPS support, are consistent between the source and destination servers.

Restoring the backup on the destination server

To restore the backup via the command line, refer to the relevant documentation.

1. Sign in as an administrator to your destination Discourse instance.
2. Navigate to /admin/backups/settings, and enable the allow restore setting.
3. Go to /admin/backups and click the Backup files tab. Upload the backup file you downloaded earlier by clicking the Upload button:
   
   
4. After the upload completes, click the ⋮ (more options) menu next to the uploaded backup, then click Restore:
   
   
5. Confirm by clicking Yes when prompted.

The restoration process will begin. This may take some time depending on your database size. After the process completes, you’ll be logged out automatically.

Finishing up and logging in

1. Log into your destination Discourse instance with your admin credentials.
2. If the site was backed up using HTTPS, ensure HTTPS is enabled on the new server. If not properly configured, use the Rails console to disable the “force https” setting temporarily.
3. Re-enable any optional configurations by editing the app.yml file and rebuilding your instance. This may include:
   • Enabling CDN support.
   • Installing additional plugins.
   • Setting HTTPS configurations.

Common issues and solutions

Backup file is not restoring

• Check that the Discourse and PostgreSQL versions match between the source and destination servers.

Unable to log in after restoration (with HTTPS enabled)

• Use the Rails console to disable force https temporarily by running:

  SiteSetting.force_https = false
  

Last edited by @pfaffman 2025-09-12T22:10:57Z

Check document

Perform check on document:

[bayardo.rivas]

이 가이드가 11년이 지난 지금에도 여전히 유효한가요?

저는 Ubuntu에서 Discourse를 운영 중이며, OS를 20.04 LTS에서 24.04 LTS로 업그레이드하면서 다운타임을 최소화하고 싶습니다. AWS에서 사용하고 있습니다.

[merefield (Robert)]

@bayardo.rivas

11년 뒤에도 여전히 유효한가요?

좀 비관적인 것 같네요

@Discourse

마지막으로 @SaraDev 님이 수정했습니다 2024-11-21T00:47:52Z

[Jagster (Jakke Flemming)]

아니면… 현실적인가요? 즉, 이런 종류의 문제 때문에:

@Discourse

소스 서버와 대상 서버 간에 Discourse와 PostgreSQL 버전이 일치하는지 확인하세요.

[bayardo.rivas]

이것이 문서에 나와 있는 내용과 같은지 우려를 표하고 질문하는 것은 타당하다고 생각합니다. 최근 Discourse 포럼을 업그레이드했는데, 시스템이 깨지는 문제가 발생했습니다. 최신 버전으로만 업그레이드했을 뿐인데, Discourse의 코어 시스템에 이제 포함되는 새로운 플러그인 관련 문제인 것 같습니다.

더 새로운 운영체제가 설치된 다른 인스턴스로 이동하는 것은 상당한 변경 사항이라고 생각합니다. 이 접근 방식을 시도할 계획이라면, 가능한 한 많은 피드백을 얻고 싶습니다.

유용한 조언을 주시면 감사하겠습니다. 감사합니다.

[merefield (Robert)]

이 가이드는 해당 특정 변경 사항의 범위에서 약간 벗어납니다.

코어 업그레이드는 일반적으로 비공식적인 항목과 변경 사항이 자주 발생하기 때문에 열린 마음으로 진행해야 하는 단계입니다.

하지만 마이그레이션과는 다르며, 이 가이드는 11년 전 것이 아닙니다

[bayardo.rivas]

댓글 남겨주셔서 감사합니다.

[Gunnar (Gunnar Helliesen)]

아직 Ubuntu 20.04를 사용 중이시라면, Docker와 aufs를 사용 중이신가요?

사용 중이시라면, 진행하기 전에 아래 내용을 꼭 읽어보세요:

Docker 업그레이드로 AUFS 스토리지 드라이버가 제거되어 Discourse가 종료되었습니다

I run a Discourse forum installation on Ubuntu 20.04.6 LTS. The Docker image uses AUFS for storage. Today, I installed upgrades via sudo apt upgrade. Now the Discourse forum is no longer accessible, and it appears to be because a Docker upgrade removed the AUFS storage driver. I see plenty of guides to configuring Docker to use Overlay2 instead, but I don’t see any guidance on how to migrate my existing Discourse installation to use Overlay2, especially now that I can’t start Docker to mount m…

[pfaffman (Jay Pfaffman)]

그렇다고 생각했지만, 자세히는 보지 않았습니다. 아니요. DNS가 새 서버를 가리키지 않으면, 새 사이트는 Let’s Encrypt에서 키를 가져오지 못합니다. 따라서 백업을 만들고, 백업을 전송한 후, DNS를 새 서버로 전환하고, 다시 빌드해야 합니다.

다운타임을 최소화하려면 rsync를 사용하여 Discourse 사이트를 다른 VPS로 이동하는 것을 권장합니다. 이 방법은 SSL 키를 복사하므로, 다시 빌드할 때 새 서버가 즉시 사용 가능한 상태가 됩니다.

아직 Postgres 15로 업그레이드하지 않았다면(심지어 업그레이드했더라도), --exclude postgres* 옵션을 사용하고 다시 빌드한 다음, 메인 사이트의 백업을 만들어 새 서버에 복원하는 것을 권장합니다(제가 실제로 사용하는 방법입니다). 복원이 완료되면 DNS를 전환합니다. rsync 안내문에는 데이터베이스를 종료하여 원본 데이터베이스 파일을 복사할 수 있도록 되어 있습니다. 이 방식이 잘 작동하지 않는 경우가 있으므로, 저는 주로 데이터베이스 전용 백업을 만들어 복원합니다.

수정: 이 내용을 OP(원문)에 추가했습니다.

@Discourse

@pfaffman이 추가한 면책 조항 2025-09-12T05:00:00Z.

이 안내문은 현재 HTTPS와 Let’s Encrypt를 사용하므로 잘 작동하지 않습니다. 이 경우 새 서버가 키를 요청할 수 있도록 DNS가 새 서버를 가리켜야 합니다. rsync를 사용하여 Discourse 사이트를 다른 VPS로 이동하는 것을 권장합니다(필요하다면 --exclude postgres*를 사용하고, 명령줄에서 데이터베이스를 백업 및 복원하는 방식). 이 방법은 깔끔한데, 방법을 안다면 로컬 DNS를 새 서버로 설정하여 나머지 인터넷 사용자는 여전히 기존 사이트를 보는 동안 새 서버가 정상 작동하는지 테스트할 수 있기 때문입니다.

[nathank (Nathan Kershaw)]

제이, 고마워! 지난 몇 달간 OP의 지시를 따르려 할 때 왜 URL / DNS / LetsEncrypt 관련 부분에서 좀 막혔는지 궁금했거든.

결국 새 사이트에는 서브도메인을 사용하고, 새 서버에서 복구된 사이트가 정상적으로 작동하는지 확인한 뒤 DNS / URL을 빠르게 전환해서 해결했어. 하지만 그 과정은 좀 불안하고 힘들었지 (특히 그 뒤에 이어지는 리맵 whack-a-mole 작업은 정말!).

왜 그 모든 과정이 필요했는지는 이제 이해가 돼. 그리고 rsync를 사용하면 일부 번거로움을 피할 수 있다는 것도 알게 되어 좋았어.

현재 상태가 좀 혼란스럽고, 앞으로 최선의 방법은 무엇인지 확신이 서지 않아서, 여기 명확한 지침이 있다면 다른 사람들에게 정말 도움이 될 것 같아. 혹시 @SaraDev 님이 OP 전체를 다시 작성하면서 그 면책 조항을 포함시켜 줄 수 있을까?

[pfaffman (Jay Pfaffman)]

@nathank

최근에 OP의 지시를 따르려 할 때 URL / DNS / LetsEncrypt 관련 부분에서 왜 조금 막혔는지 궁금해했습니다.

그래서 저는 이 지시를 따르지 않는 것을 제안했습니다.

@nathank

현재 상황이 다소 혼란스럽기 때문에, 여기에서 명확한 지시가 다른 사람들에게 정말 도움이 될 것だと思います.

제가 연결한 rsync 주제를 따르고 이 지시사항을 무시하거나 삭제하는 것이 사람들에게 도움이 될 것だと思います.

제가 놓치고 있는 것이 있나요?

[Ethsim2 (Ethan)]

여기서 겪은 마이그레이션의 가장자리 사례(edge case)를 하나 추가합니다. 다른 분들에게 도움이 될 수 있기를 바랍니다.

독립형 Discourse 인스턴스를 새로운 VPS로 이전하는 과정에서 Let’s Encrypt/SSL 관련 가장자리 사례에 부딪혔습니다. 따라서 이 가이드를 따르는 다른 분들에게 도움이 될 수 있도록 정확한 진단 및 복구 단계를 정리해 보았습니다.

제 경우, app 내부의 nginx가 시작되지 않았는데, 그 이유는 /var/discourse/shared/standalone/ssl/에 있는 두 개의 .cer 파일이 모두 0바이트 파일이 되었기 때문이었습니다:

PEM_read_bio_X509_AUX() failed

재구축(rebuilding)을 시도하자 인증서 발급이 다시 시도되었고, 반복된 시도 끝에 Let’s Encrypt의 인증서 발급 속도 제한(rate limit)에 도달했습니다. 기존 서버에서 여전히 유효한 인증서 파일만 복사해서는 충분하지 않았습니다. app를 시작하면 다시 0바이트 파일로 대체되었기 때문입니다.

결국 문제를 해결한 방법은 app를 중지한 뒤, 기존 서버에서 작동하는 /var/discourse/shared/standalone/ssl/ 디렉터리 뿐 아니라 해당 /var/discourse/shared/standalone/letsencrypt/ 상태까지 모두 복사한 다음 컨테이너를 다시 시작하는 것이었습니다.

전체 순서를 여기에서 문서화했습니다:

server_migration_diagnosing_standard_ssl.md

이것은 공식 마이그레이션 또는 HTTPS 문서의 대체물이 아니라, 이 특정 마이그레이션에 대한 진단/복구 노트입니다.

관련된 0바이트 .cer 실패 모드에 대해 다루는 오래된 Meta 토픽도 있습니다:

Let's Encrypt- empty *.cer files

I can’t connect to a new standard 30-minute install. AWS Lightsail, 2GB memory, Ubuntu 18.04 LTS x64 with :443 open. The problem is that the Let’s Encrypt *.cer files are empty. Why? nginx logs root:/var/log/nginx# ls -ltrh -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 error.letsencrypt.log -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 access.letsencrypt.log -rw-r–r-- 1 www-data www-data 1.8M Dec 6 08:19 error.log tail error.log PEM_read_bio_X509_AUX() failed (SSL: error:0909006C:PE…