Move a Discourse site to another VPS with rsync

오늘 새 VPS로 마이그레이션을 진행했는데, 최근 업데이트에서 구버전 운영체제 차단 문제에 부딪치는 분들이 꽤 있는 것 같아 경험을 공유해 보려 합니다 :blush:

저는 Digital Ocean을 사용하므로 새로운 드롭렛(droplet)을 생성했습니다.

구 VPS = Ubuntu Server 18.04.6 LTS

신규 VPS = Ubuntu Server 23.10

새 VPS에서 기본적인 정리를 수행했습니다 - 필요에 맞게 수정하세요:

Apt-get update

Apt-get upgrade

Apt-get install fail2ban

ufw default deny incoming

ufw default allow outgoing

ufw allow ssh

ufw allow http

ufw allow https

ufw enable

이후 Discourse를 위한 새 빈 디렉터리를 생성했습니다:

sudo mkdir -p /var/discourse

그다음 Docker를 설치했습니다:

wget -qO- https://get.docker.com/ | sh

그리고 DNS의 TTL을 30분에서 10분으로 변경했습니다(GoDaddy가 허용하는 최소값).

구 서버에서는 지난밤의 Discourse 데이터베이스 백업의 로컬 사본을 다운로드했습니다(로컬 백업은 아무리 많아도 지나치지 않습니다). 또한 app.yml 사본도 로컬 PC로 다운로드했습니다.

위에서 몇몇 분들이 제안한 대로 “루트-투-루트(root-to-root)” rsync를 수행했습니다. DNS 혼란을 피하기 위해 호스트명 대신 IP 주소를 사용했습니다. 또한 위에서 제안된 대로 -avz 옵션을 사용했습니다:

rsync -avz root@old.ip.address.here:/var/discourse /var

참고로 제 discourse 폴더는 25GB입니다.

구 서버에서 새 서버로 rsync하는 데 약 25분이 걸렸습니다. 이는 동일한 LON1 리전에 있는 두 Digital Ocean 드롭렛 사이의 전송이므로, 환경에 따라 결과가 다를 수 있습니다.

rsync를 마치고 리빌드를 시도한 후, @piratdavid가 postgres database system is shut down 관련으로 겪었던 동일한 오류가 발생했습니다.

그래서 구 VPS에서 앱을 중지했습니다:

./launcher stop app

그리고 이번에는 변경 사항만 포함하도록 rsync를 다시 실행했습니다:

rsync -avz --delete root@old.ip.address.here:/var/discourse /var

이후 구 Discourse 앱을 다시 시작하고 즉시 유지보수 모드(Maintenance Mode)로 전환했습니다. 이렇게 하면 사용자가 여전히 사이트에 접근할 수 있으며 일반적인 유지보수 경고 메시지를 볼 수 있습니다.

이로써 새 VPS 작업을 위한 시간도 확보됩니다 :blush:

로컬 PC의 HOSTS 파일을 업데이트하여 브라우저 경고나 문제 없이 새 VPS의 discourse에 접근할 수 있도록 했습니다.

새 VPS에서 다음을 실행했습니다:

./discourse-setup

이것은 app.yml 파일의 RAM 및 CPU 설정을 자동으로 업데이트하기 위함입니다.

그다음 새 VPS에서 앱 리빌드를 수행했습니다:

./launcher rebuild app

간단한 스모크 테스트를 수행했고, 모두 정상적으로 작동했습니다.

DNS 업데이트 완료 - 작업 종료.

상세한 주제에 대해 감사드립니다, 여러분 :smiley:

4개의 좋아요