# 같은 DNS 이름을 유지하면서 Discourse를 다른 서버로 이전하는 방법
**URL:** https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572
**Category:** Self-hosting
**Created:** [1월 9, 2021, 5:03오전 UTC](https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572 "2021-01-09T05:03:08Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [1월 9, 2021, 5:03오전 UTC](https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572/1 "2021-01-09T05:03:08Z")
개인 호스팅에서 Amazon LightSail 서버로 Discourse를 마이그레이션하려고 합니다. 포럼을 검색하고 서버 마이그레이션 및 Discourse 설정 관련 게시물을 모두 읽어보았지만:
[Move your Discourse Instance to a Different Server](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721)
[Restore a backup from the command line](https://meta.discourse.org/t/restore-a-backup-from-command-line/108034)
[How To Install Discourse on Ubuntu 18.04 | DigitalOcean](https://www.digitalocean.com/community/tutorials/how-to-install-discourse-on-ubuntu-18-04)
[discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub](https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md)
제가 이해한 과정은 다음과 같습니다:
1. 새로운 Discourse 서버 설치
2. 기존 Discourse에서 백업 내보내기 (현재 백업은 S3에 저장되도록 설정되어 있지만, 이는 수동 파일 백업이 될 것이라 이해합니다)
3. 새로운 Discourse에 백업 가져오기 (S3에서 자동으로 가져올 수 없으므로 수동으로 수행해야 한다고 이해합니다)
여기서 1단계 수행 시 몇 가지 제약 사항으로 인해 막혀 있습니다. 단일 도메인 이름을 가지고 있으며, 새로운 서버에도 동일한 도메인 이름을 유지하고 싶고, 다운타임이 없기를 원합니다 (새 서버 설정을 완료하고 백업을 복원한 후, 마지막으로 DNS 항목을 새 서버를 가리키도록 변경하여 두 서버가 동시에 실행되는 동안 다운타임을 피하려는 것이 목표입니다).
제가 이해하기로는, 새로운 Discourse 서버를 설정할 때 기존 서버의 `app.yml`을 새 서버로 복사한 후 `discourse-setup`을 실행할 수 있습니다. 여기서 제가 발견한 문제는, 이렇게 하면 기존 서버와 동일한 DNS 이름을 사용하게 된다는 점입니다(이것은 제가 원하는 것입니다). 하지만 두 가지 문제를 예상하고 있으며, 해결 방법을 찾고 있습니다.
1. 도메인 이름이 여전히 구 서버를 가리키고 있으므로, Let’s Encrypt 인증서가 새 서버에 대해 SSL 인증서를 생성하지 못합니다.
2. SSL 인증서가 없으면(구 서버 설정은 SSL만 사용하도록 되어 있으며 이는 `app.yml`에 그대로 유지됩니다) 서버가 시작되지 않습니다.
3. DNS 이름 리다이렉션을 사용하여 Discourse 서버에 연결해 보았지만, 입력한 URL이 `app.yml` 설정과 일치하지 않으면 NGINX 또는 Discourse가 작동하지 않고 브라우저에서 연결 시 오류가 발생합니다. 따라서 웹 인터페이스 없이 백업 복원 프로세스를 시작할 수 없습니다.
그러면 기존 서버의 `app.yml`을 사용하여 새로운 Discourse 서버 설정을 완료하고, 백업을 복원한 후 DNS를 전환하는 방법은 무엇인가요? 아니면 이를 수행하는 더 쉬운 다른 방법이 있나요?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [1월 9, 2021, 2:19오후 UTC](https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572/2 "2021-01-09T14:19:13Z")
같은 S3 버킷을 사용하지 않을 경우, 백업이 S3 파일을 다운로드하도록 강제하는 숨겨된 설정이 있습니다. 설정 파일에서 해당 설정의 이름을 확인한 후 rails 콘솔에서 값을 설정할 수 있습니다. 이 주제를 다루는 게시물이 있지만, settings.yml 파일을 직접 확인하는 것이 가장 쉽습니다.
discourse-setup을 실행할 필요는 없으며, app.yml 파일을 복사하고 다시 빌드하기만 하면 됩니다.
Let’s Encrypt 인증서는 rsync로 복사할 수 있습니다. 실제로 /var/discourse 디렉터리 전체(일부 로그 등은 제외하고)를 복사해도 됩니다.
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [1월 9, 2021, 3:00오후 UTC](https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572/3 "2021-01-09T15:00:41Z")
이상적으로는 “lift and shift”(원격 이전)을 하는 것이 목표이지만, Amazon Lightsail의 경우 기존 이미지를 가져올 수 없기 때문에 이것이 불가능합니다. 따라서 네, 동일한 S3를 그대로 사용하게 됩니다.
당신의 접근 방식이 lift and shift에 가장 가까운 것 같습니다. 제가 이해한 바로는, 원래 서버의 _/var/discourse_ 폴더 전체를 tar/gz로 압축한 후 새 서버에 압축을 풀고 `discourse start`를 실행한 뒤, DNS를 bee 서버로만 다시 지정하면 되는 것이 맞나요? 새 서버에서 Discourse를 다시 빌드해야 하나요? 폴더 외부의 Nginx, Docker 및 기타 의존성은 어떻게 처리해야 하나요?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [1월 9, 2021, 11:17오후 UTC](https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572/4 "2021-01-09T23:17:30Z")
네, 파일은 본인이 합리적으로 판단하여 이동하시면 됩니다. 네, 새 컨테이너를 빌드하고 실행하려면 리빌드가 필요합니다.
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [1월 20, 2021, 9:21오전 UTC](https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572/5 "2021-01-20T09:21:02Z")
고맙습니다. 분명히 리프트 앤 쉬프트(Lift and Shift)가 내가 생각했던 것만큼 깔끔하지는 않더군요. 원활한 리프트 앤 쉬프트 작업을 위해 이전과 이후에 몇 가지 점검을 수행해야 합니다. (Postgres를 12.0에서 13.0으로 업그레이드하는 과정에서 리프트 앤 쉬프트 절차에 대해 몇 가지 교훈을 얻었습니다.) Amazon LightSail 서버(1GB RAM)로 이전하려는 분들을 위해 향후 참고용으로 단계별 가이드를 공유합니다:
**기존 서버**
- S3에 백업 생성
- `cd /var/discourse`
- `./launcher rebuild` # 원활한 전환을 위해 최신 빌드 가져오기
- `./launcher cleanup` # 오래된 데이터를 제거하고 패키지 크기를 줄이기 위해 정리
- `./launcher stop app` # 이 단계를 건너뛰면 나중에 Postgres로 재빌드할 때 실패할 수 있습니다
- `tar -zcvf /var/discourse discourse.tar.gz`
**새로운 Amazon LightSail 서버**
- Amazon에서 Ubuntu 20.20 이미지 설치 (1GB RAM)
- [Docker](https://www.digitalocean.com/community/tutorials/how-to-install-discourse-on-ubuntu-18-04) 설치
- [2GB 스왑](https://meta.discourse.org/t/create-a-swapfile-for-your-linux-server/13880) 생성 # 이 단계를 건너뛰면 재빌드가 실패할 수 있습니다
- [`vm.overcommit_memory=1`](https://linuxize.com/post/how-to-add-swap-space-on-ubuntu-18-04/) 설정 # 이 단계를 건너뛰면 재빌드 중 Postgres에서 실패할 수 있습니다
- 기존 서버에서 _discourse.tar.gz_를 FTPS/전송
- `tar -zxvf discourse.tar.gz -C /`
- `cd /var/discourse`
- `app.yml`에서 [`UNICORN_WORKERS`](https://meta.discourse.org/t/problems-with-install-cloud-md-directions/43314/43)를 _2_로 설정 # 1GB RAM 환경에서 2보다 높게 설정하면 과도한 디스크 활동으로 인해 스왑 및 스로틀링이 발생할 위험이 있습니다
- `./launcher rebuild`
- DNS를 변경하여 새로운 Amazon 서버를 가리키도록 설정
Discourse 설정 과정을 거치지 않고 서버를 이전(리프트 앤 쉬프트)하는 더 쉬운 방법이 있을까요?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [1월 20, 2021, 3:46오후 UTC](https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572/6 "2021-01-20T15:46:08Z")
> [@RBoy](#):
>
> discourse 설정 과정을 거치지 않고?
`discourse-setup`을 실행하지 않는다는 의미인가요, 아니면 Discourse 실행에 필요한 컨테이너를 빌드하지 않는다는 의미인가요? 후자를 의미하신다면, 기존 이미지를 새 서버에서 사용할 수 있는 레포지토리에 푸시하는 방식으로 가능하지만, 초보자가 쉽게 처리할 수 있는 일은 아닙니다.
PG13 업그레이드로 인해 프로세스가 복잡해졌습니다. 새 서버에서 새 이미지를 처음부터 빌드하고 기존 서버의 백업/복원을 수행하는 것이 조금 더 쉬웠을 수 있지만, 새 서버에서 Let’s Encrypt 인증서를 설정하는 부분은 여전히 다소 까다로운 작업이 될 것입니다.
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [1월 20, 2021, 9:54오후 UTC](https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572/7 "2021-01-20T21:54:12Z")
> [@pfaffman](#):
>
> 하지만 새 서버에서 Let’s Encrypt 인증서를 받는 과정에서 여전히 몇 가지 복잡한 부분이 있을 것입니다.
네, 그게 바로 새 서버에서 `./discourse-setup`을 실행한 후 S3 이미지에서 복원하는 것을 막았던 유일한 이유였습니다. (DNS가 여전히 구 서버를 가리키고 있고, 브라우저에서 IP 주소로는 Discourse가 응답하지 않으므로 웹 관리자 콘솔에 접근하지 않고 어떻게 이 작업을 수행할지도 문제입니다.) 저는 라이브 시스템이 있었고 구 시스템에서 새 시스템으로 DNS를 즉시 전환해야 했기 때문에, Let’s Encrypt 인증서가 없는 것이 저에게 유일한 장애물이었습니다.
만약 구 시스템에서 새 시스템으로 인증서를 이전하는 방법, Let’s Encrypt 오류 없이 `./discourse-setup`을 완료하는 방법, 그리고 웹 콘솔 없이 S3 백업에서 복원하는 방법이 있다면, 이것이 더 간단한 방식이 될 것입니다.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [1월 20, 2021, 10:30오후 UTC](https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572/8 "2021-01-20T22:30:46Z")
`containers` 안의 `yml` 파일들을 복사해 온다면 `discourse-setup`은 필요하지 않습니다(새 서버에서 메모리 파라미터가 다른 경우 조정할 수는 있지만, 나중에 해도 됩니다). 그냥 `./launcher rebuild app`을 실행하면 됩니다.
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [1월 22, 2021, 2:50오후 UTC](https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572/9 "2021-01-22T14:50:01Z")
네, 말씀하신 내용을 어느 정도 이해한 것 같은데, 확실하지 않아서 제 이해를 다시 정리해 보겠습니다.
원래 서버에서는 Discourse를 S3에 백업하도록 설정되어 있었습니다(설정 및 사이트 콘텐츠).
`containers`에서 `yml` 파일을 복사하면 원래 서버의 모든 구성이 새 서버로 복사되므로, 이제 새 서버에서는 `discourse-setup`을 실행할 필요가 없고, 대신 `./launcher rebuild app`을 실행하면 원래 서버의 구성을 사용하여 최신 이미지를 다운로드하고 Discourse를 설정하게 됩니다.
이제 해결해야 할 두 가지 문제가 있습니다:
1. Let’s Encrypt 인증서를 어떻게 이전하나요? (DNS가 여전히 원래 서버를 가리키고 있어 인증서를 재생성할 수 없으며, `./launcher rebuild app`을 실행하기 전에 이 작업을 수행해야 한다고 추측합니다.)
2. 재빌드(rebuild) 후 S3 백업에서 Discourse(설정 + 콘텐츠)를 어떻게 복원하나요? DNS가 여전히 원래 서버를 가리키고 있는 상황에서 IP 주소나 localhost를 사용하여 Discourse 관리자 웹 인터페이스에 접근할 수 있는 방법이 있나요, 아니면 S3 백업을 콘솔을 통해 복원할 수 있나요?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [1월 22, 2021, 4:17오후 UTC](https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572/10 "2021-01-22T16:17:27Z")
기존의 /var/discourse를 복사하면 인증서가 함께 복사되며, 재구성이 예상대로 작동합니다.
컨테이너 안에서 명령줄을 통해 복원할 수 있습니다.
---
### Author:  [@kenkendk](https://meta.discourse.org/u/kenkendk)
#### Post date: [4월 12, 2024, 10:12오전 UTC](https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572/11 "2024-04-12T10:12:20Z")
상세한 단계에 대해 감사합니다. 저도 비슷한 작업을 해야 했는데, 새로운 호스트로 이전하는 과정이었어요.
사이트가 정상적으로 작동하고 있었기 때문에 백업을 통해 복구하는 것보다는 여기 있는 단계를 따르는 게 나을 것 같아서 그렇게 했죠.
거의 성공했지만, 새 호스트에서 재빌드(rebuild)가 실패했습니다.
알고 보니 두 호스트의 UID/GID 매핑이 완전히 일치하지 않아서, Postgres를 시작할 때 데이터 폴더의 소유권이 잘못되어 오류가 발생했네요.
이런 문제는 다른 상황에서도 발생할 수 있으며, [다행히 해결 방법이 있습니다](https://meta.discourse.org/t/postgresql-13-update-from-postgresql-10-fails/192865/10).
이 게시물에서 설명하는 시나리오에 대해 한 가지 추가적인 세부 사항이 있습니다. 컨테이너가 아직 빌드되지 않았기 때문에 이 단계에서는 `./launcher enter app` 명령이 작동하지 않는다는 점입니다. 재빌드에는 상당한 시간이 소요되므로, 빌드를 수행 중인 컨테이너의 이름을 `docker ps` 명령으로 확인한 뒤 컨테이너에 진입할 수 있었습니다:
```plaintext
docker exec -it bash
chown -R postgres:postgres /shared/postgres_*
```
이후 재빌드를 다시 시도하면 실패합니다(또는 CTRL+C로 중지할 수 없습니다). 재빌드가 멈춘 후 다시 실행하면 권한 문제가 해결됩니다:
```plaintext
./launcher rebuild app
```
그리고 다시 정상적으로 실행됩니다 😅 .
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [4월 12, 2024, 12:08오후 UTC](https://meta.discourse.org/t/how-to-migrate-discourse-from-one-server-to-another-with-the-same-dns-name/175572/12 "2024-04-12T12:08:14Z")
> [@RBoy](#):
>
> [2GB 스왑 생성](https://meta.discourse.org/t/create-a-swapfile-for-your-linux-server/13880) # 이 작업을 수행하지 않으면 재구축이 실패할 수 있습니다
1GB RAM을 사용하는 경우, 재구축 실패를 방지하기 위해 최소 4GB의 스왑을 생성하도록 하십시오. 관련 링크: [3.1.x to 3.2.0 upgrade hangs/fails on 1GB instance](https://meta.discourse.org/t/3-1-x-to-3-2-0-upgrade-hangs-fails-on-1gb-instance/293743/)