서버의 새 인스턴스로 복원 시 이미지 최적화 일시 중지

새 서버로 Discourse 인스턴스를 마이그레이션하려고 합니다. 서버의 디스크 공간이 제한되어 있어, 먼저 다음을 수행하고 싶습니다.

초기 업로드된 DB를 복원한 후 이미지 최적화를 일시 중지하는 방법과, 이를 다시 활성화하는 방법은 무엇인가요?

복원이 정상적으로 완료되었는지 확인한 후 백업 파일을 삭제할 수 있도록 하려고 합니다.

제 백업 파일은 약 200GB이며, ‘백업에 생성된 섬네일 포함’ 설정은 체크되어 있지 않습니다. 이 옵션을 비활성화하면 백업 파일 크기가 줄어지지만, 복원 후 모든 게시글에 대한 리베이크(rebake)가 필요합니다.

따라서 인스턴스가 백업 파일을 유지하면서 이미지 최적화를 시작하게 되면 디스크 공간이 부족해질 것입니다.

더 많은 공간이 필요하면 더 많은 공간이 필요합니다.

하지만 이미지를 rsync로 복사하고 데이터베이스만 복원하는 것이 더 나을 수도 있습니다. 이렇게 하면 업로드된 파일의 두 가지 사본을 만들 필요가 없고(썸네일을 다시 생성할 필요도 없으며)

도와주려고 해줘서 감사합니다.

해석해보았지만, 제 복구가 왜 잘되지 않았는지 이제 확신이 들었습니다.

제 주요 문제는 이전 인스턴스가 PostgreSQL 버전 12에 기반하고 있는데, 이를 업그레이드하는 방법을 찾지 못해 새로운 인스턴스로 이사를 시도했다는 점입니다.

새로 설치한 환경에 데이터베이스만 복원하는 것이 가능한지 알고 싶습니다.

인스턴스를 시작하려고 하면 500 오류 코드가 반환되어 처음부터 다시 시작해야 했습니다.

저라면 Move a Discourse site to another VPS with rsync 가이드를 따르되, postgres 파일은 복사하지 않는 방식을 선택하겠습니다.

이후 데이터베이스만 백업하고 이를 복원합니다. 백업 파일도 rsync로 복사한 뒤, 명령줄에서 복원 작업을 수행하면 됩니다.

아마도 아주 오래된 버전을 사용하시는 건가요? 복원 작업이 정상적으로 완료된 것처럼 보였나요?

도와주셔서 감사합니다.

네, 하지만 웹 GUI를 사용하여 예상된 절차대로 간단한 복구를 수행하려면 백업 파일 크기의 4배(+4x)의 여유 공간이 필요합니다.

다음은 그 방법입니다:

  1. 백업 파일을 업로드합니다 (또는 /var/discourse/shared/standalone/backups/default 디렉토리로 rsync합니다).
  2. 복구가 초기화되면 백업 파일(file.gz)이 /var/discourse/shared/standalone/tmp/restores/로 복사됩니다.
  3. 복구 중에는 /var/discourse/shared/standalone/tmp/restores/ 폴더에 있는 백업 파일이 압축 해제됩니다.
  4. 임시 폴더에서 업로드 파일은 원본 위치로 rsync되고, SQL 덤프는 pg 데이터베이스에 삽입됩니다.

제가 성공적으로 복구를 수행한 방법입니다.

복구 과정에서 Discourse가 복구 폴더에서 임시 폴더로 파일을 복사한 시점에, SSH를 통해 업로드한 원래 백업 파일을 삭제했습니다.

또한, Discourse가 SQL 삽입과 stat rsync를 완료하여 임시 폴더의 압축 해제된 파일을 /var/discourse/shared/standalone/uploads/로 복사하는 동안, 복구 프로세스를 중단하지 않고 SSH를 통해 임시 폴더의 bakupxxx.tar.gz 파일을 수동으로 삭제했습니다.

인스턴스가 온라인이 되고 rsync가 완료된 후에 다음을 실행했습니다:

rm -rf /var/discourse/shared/standalone/tmp/restores/default/*

대용량 백업의 복구 프로세스가 멈춘 것처럼 보이거나 웹에서 인스턴스가 500 오류 코드를 반환하기 시작할 때(저에게는 두 번 발생했습니다), 앱에 진입하여 복구 프로세스를 확인할 수 있습니다.

cd /var/discourse
./launcher enter app

ps aux | grep restore


또한, 제 DB 복구가 너무 오래 걸렸기 때문에

cd /var/discourse
./launcher enter app
watch -n 10 “sudo -u postgres psql discourse -c "SELECT now(), state, query FROM pg_stat_activity WHERE state != ‘idle’;"”

명령어를 사용하여 DB 복구 진행 상황을 모니터링하고, 복구가 여전히 진행 중인지 확인할 수 있었습니다.

정말 좋은 해결책이네요! 다른 분들도 이 내용을 보게 된다면, 데이터베이스만 복원하는 방식도 작동했을 것 같고 조금 더 쉬웠을 것 같습니다. 하지만 문제를 해결하셨다니 다행이네요!