전체 /var/discourse 앱 폴더를 백업하고 복원하는 방법?

전체 /var/discourse 폴더를 백업하고 복원하는 방법?

보통의 백업 및 복원 과정에서의 문제로 인해, 전체 /var/discourse 폴더를 백업하여 다른 서버에서 재사용할 수 있는지 궁금했습니다. 다음과 같이 진행했습니다…

프로덕션 서버에서:

rsync_opts="\
   --recursive \
   --links \
   --hard-links \
   --safe-links \
   --owner \
   --group \
   --perms \
   --times \
   --delete \
   --sparse \
   --compress \
   --partial \
   --rsh=ssh
"
dir=/var/discourse
rsync  $rsync_opts "$dir/" root@xx.xx.xx.xx:"/var/production-backup/$dir"

스테이지 서버에서:

docker를 설치합니다.

rsync --recursive --links --hard-links --safe-links --owner --group --perms --times --delete --sparse --compress --partial /var/production-backup/var/discourse/ /var/discourse

그러나 502 Bad Gateway 오류가 발생합니다.

조사 중입니다.

cd /var/discourse

./launcher start app

root@whonix-app:/var/www/discourse# service postgresql status
12/main (port 5432): down
root@whonix-app:/var/www/discourse# service postgresql start
[....] Starting PostgreSQL 12 database server: main[....] Error: The cluster is owned [FAILoup id 116 which does not exist ... failed!
 failed!

다음과 같은 수정을 시도해 보았습니다:

chown -R postgres.postgres /etc/postgresql
chown -R postgres.postgres /shared/postgres_*
chown -R postgres.postgres /var/lib/postgresql
chown -R postgres.postgres /var/log/postgresql
chown -R redis.redis /etc/redis/redis.conf
chown -R redis.redis /shared/redis_data
chown -R redis.redis /var/run/redis
chown -R redis.redis /var/lib/redis
chown -R redis.redis /var/log/redis
chgrp -R ssl-cert /etc/ssl/private

하지만 도움이 되지 않았습니다.

root@whonix-app:/var/www/discourse# service postgresql start
[....] Starting PostgreSQL 12 database server: main[....] Error: /usr/lib/postgresql/12/bin/pg_ctl /usr/lib/postgresql/12/bin/pg_ctl start -D /shared/postgres_data -l /var/log/postgresql/postgresql-12-main.log -s -o -c config_file="/etc/postgresql/12/main/postgresql.conf" exited with status 1: 2020-05-25 10:20:10.501 UTC [603] FATAL: database files are incompatible with server 2020-05-25 10:20:10.501 UTC [603] DETAIL: The data directory was initialized by PostgreSQL version 10, which is not compatible with this version 12.2 (Debian 12.2-2.pgdg100+1). pg_ctl: could not start server Examine the lo[FAILput. ... failed!
 failed!

왜 이러한 파일 권한 문제가 발생하는 것일까요?

왜 한 서버에서 다른 서버로 전체 폴더를 단순히 복사하는 것만으로 postgres가 10 버전에서 12 버전으로 업데이트되는 것일까요? 제가 무언가를 잘못하고 있는 것 같습니다.

한 서버의 전체 discourse 앱을 백업하고 다른 서버로 이동하는 방법에 대한 지침을 공유해 주실 수 있을까요?

Discourse는 phabricator를 사용하지 않나요?

오타였습니다. 'discourse’를 쓰려던 것이었습니다. 오타는 수정했습니다. 원래 질문은 그대로입니다.

이것은 /var/discourse 폴더 전체를 이동하지 않습니다. 이 지침이 제 환경에서는 작동하지 않는다는 점을 알고 있습니다. 따라서 더 “완전한” 1:1 “하드카피” 방식으로 백업하고 싶었습니다.

컨테이너를 종료한 후, tmp, backup, cache 디렉터리(그리고 하나 더 있는 것 같은데?)를 제외하고 전체를 새 서버로 복사하면 됩니다. 그렇게 하면 작동할 것입니다. 저도 최근에 비슷한 이유로 비슷한 작업을 해본 적이 있습니다.

하지만 여전히 손상된 인덱스 문제를 해결해야 합니다.

Docker 버전 차이로 인해 문제가 발생하는 것 같습니다. (그리고 이로 인해 실패하게 됩니다.)

원래 서버
docker-engine 17.05.0~ce-0~debian-stretch

vs 더 새로운 (스테이지) 서버
docker-engine 17.05.0~ce-0~debian-stretch

이로 인해 원래 서버에는 Postgres 버전 10이, 더 새로운 (스테이지) 서버에는 이미 Postgres 12가 설치되어 있습니다.

이것이 필수적인가요? 더 쉬운 방법이 있을까요? 왜 그대로 복사하고 복원하는 것이 아니라 모든 것을 복사하지 않는 것이 필요한가요?

설명할 수 없는 권한 문제로 이어집니다. 권한을 깨뜨리지 않고 복사하는 것이 가능해야 합니다. 또한 모든 권한 문제를 완전히 수정했는지 확신이 서지 않습니다.

네, 하지만 현재 아직 작동하고 있는 것을 최소한 재현할 수 있을 때까지는 그 작업을 진행하는 것이 훨씬 더 안전하다고 생각합니다.

단순히 /var/discourse 디렉터리를 "tar로 압축"하여 다른 머신으로 이동하고, 압축을 해제한 후 discourse 앱을 시작할 수 없습니다.

주요 이유 중 하나는 Discourse를 빌드/부트스트랩할 때(기억이 맞다면 launcher가) 기본 Discourse 컨테이너(이미지)가 존재하는지 확인하고, 없다면 기본 discourse Docker 이미지를 가져와 해당 기본 docker 이미지를 컨테이너로 시작하기 때문입니다.

그 기본 git pull 이후, 빌드 프로세스는 또 다른 docker 이미지(앱)를 빌드합니다.

이 두 개의 docker 이미지(기본 이미지와 앱 이미지)는 /var/discourse 내부에 존재하지 않으므로, /var/discourse를 tar로 압축하는 것은 부분적인 "해결책"에 불과합니다(이 용어를 느슨하게 사용하여).

이 Discourse docker 이미지들은 docker 이미지로 빌드되며 Docker의 일부입니다. 그것들은 /var/discourse에 "존재"하는 것이 아니라, 그곳에서 빌드된 후 docker 이미지로 docker로 이동됩니다.

컨테이너 yml 파일을 편집하고 처음부터 다시 빌드하는 것이 가능할 수 있지만, 더 일반적인 방법은 다음을 저장하는 것입니다:

  • 컨테이너 yml 파일(들)
  • 업로드를 포함한 전체 백업

그리고 컨테이너 yammy를 편집하고, discourse-docker 저장소를 클론한 후 다시 빌드하는 것입니다.

그런 다음, 업로드를 포함한 전체 백업을 복원합니다(컨테이너의 명령줄에서).

github를 저장소로 사용하는 것은 “전체 것을 tar로 압축하는” 것과 “전체 것을” 다른 서버로 “이동하는” 오래된 unix 스타일 방식보다 더 깔끔한 해결책입니다. 그러나 "오래된 unix 방식"을 사용하더라도, 배포 디렉터리의 일부가 아닌 시스템 내 공유 라이브러리, 사용자 디렉터리의 공유 라이브러리 등이 있고, distro 루트 디렉터리에 없는 etc 파일들이 있기 때문에 이 방법은 종종 완전한 해결책을 제공하지 않습니다.

따라서, 대부분의 최신 linux 시스템에서도 우리는 apt(예를 들어 Ubuntu에서)를 사용하여 저장소를 가져옵니다. Discourse docker의 경우, 기본 컨테이너를 설정하기 위해 discourse-docker를 가져오고(빌드하고), 앱을 빌드하기 위해 다른 discourse 저장소를 가져옵니다. 따라서 /var/discourse는 (이미지를) "빌드하는 곳"이자 (데이터, 백업, 공개 정적 파일 등) "공유하는 곳"입니다.

이 요약이 조금이라도 유용했기를 바랍니다.

네, rsync -rav로 모두 복사할 수 있습니다.

앱을 postgres 10 템플릿을 사용하도록 변경하면 더 잘 작동할 수 있습니다. 하지만 가장 쉬운 방법은 현재 데이터베이스를 있는 그대로 수정하는 것일 수도 있습니다.

폴더를 이동하는 것은 가능하고, 문제없이 작동합니다. 다만, discourse-setup을 우회하고 그 과정에서 실행되는 조정/테스트를 건너뛰게 되므로 권장되는 방법은 아닙니다.

제 경우, 업그레이드된 도커 컨테이너 내부에서 더 새로운 버전의 postgres가 사용되어 postgres 마이그레이션 문제로 인해 포럼을 사용할 수 없게 되었습니다. postres에서 postgres 10 템플릿으로 변경해야 했습니다.

How to backup and restore a whole /var/discourse app folder? - #8 by neounix 링크에서 자세한 내용을 잘 설명하고 있습니다.

아마 /var/docker 폴더도 백업하고 복원해야 할 것 같습니다. 하지만 다음 내용 때문에 그것도 실패할 가능성이 있습니다:

너무 깊이 빠져들고 있군.
나라면 백업/복원을 통해 원래 문제를 해결하는 데 집중할 거야.

아마도 :rat: :rat: :rat: 구멍일지도 모릅니다.

동의합니다… 물론이죠…

@adrelanos

백업-복원 과정에는 어떤 "문제"도 없습니다. 몇 달 전 이 주제에 대해 저(@neounix)가 쓴 이 "찬사"를 보세요:

@adrelanos 님,

위 1번 게시글에서 제기하신 원래 질문으로 돌아가서, 저는 호기심 많은 성격이라 이전에 드린 답변에 완전히 만족하지 못하여 오늘 테스트를 해보았습니다.

요약하자면, 베이스 컨테이너와 앱 컨테이너에 대해 docker save를 사용하고, /var/discourse 디렉터리에 대해 tar를 사용하여 앱을 완전히 저장, 전송(백업) 및 복원할 수 있다는 것을 확인했습니다.

이 방법이 공식적으로 지원되지 않는다고 거의 확신합니다(99.99%)만, 답변을 받으실 자격이 있으시므로 대신 테스트해 보았습니다:

기본적으로, 요약된 단계는 다음과 같습니다:

  1. docker save를 사용하여 컨테이너를 저장합니다.

예를 들어, 스탠드얼론 앱을 실행 중이라면, 귀하의 구성에 따라 베이스 컨테이너와 앱 컨테이너를 다음과 같이 저장할 수 있습니다:

docker save -o /tmp/my.discourse.docker.app.tar  discourse/base:2.0.20200512-1735

그리고 또한:

docker save -o /tmp/my.discourse.docker.app.tar local_discourse/app:latest  
  1. 귀하가 언급했듯이 /var/discourse 디렉터리를 tar로 압축할 수도 있습니다:
cd /var/
tar -cvzf /tmp/my.var.discourse.tar.gz discourse

그리고 원하신다면 docker tar 파일들을 gzip으로 압축하여 아카이브할 수 있습니다:

gzip /tmp/my.discourse.docker*.tar
  1. … 그리고 이 파일들을 다른 서버로 이동하거나, 같은 서버에 아카이브하거나, 원하는 대로 처리한 후, 단계를 역순으로 수행하고 Discourse 앱을 문제없이 시작할 수 있습니다.

저는 실제로 "해봄"으로써 이를 확인했으며, 모든 컨테이너 이미지와 /var/discourse 디렉터리를 삭제했습니다. 기본적으로 모든 것을 지우고 백업에서 다시 시작했습니다(도메인이 변경되지 않았으므로 재빌드가 필요하지 않았습니다).

예를 들어, 복원하려면 위에서 저장한 docker 이미지를 가져와 이미지를 로드할 수 있습니다:

gzip -d /tmp/my.discourse.docker.app.tar.gz
docker load -i /tmp/my.discourse.docker.app.tar

gzip -d /tmp/my.discourse.docker.base.tar.gz
docker load -i /tmp/my.discourse.docker.base.tar
  1. 그런 다음, 원래의 /var/discourse 디렉터리를 tar에서 해제합니다.
cd /var
tar -xvzf /tmp/my.var.discourse.tar.gz
  1. 다음으로, 이미지가 올바르게 라벨링되었는지 확인해야 합니다:
docker images
  1. 이미지가 올바르게 라벨링되지 않았다면, 예를 들어 앱 이미지의 경우 올바르게 태그를 지정해야 합니다:
docker tag 58ffc74989af local_discourse/app:latest
  1. 그런 다음, 단순히 이렇게 하시면 됩니다:
cd /var/discourse
./launcher start app

그리고 잘 작동합니다. 저는 이를 테스트해 보았습니다(두 번).

도움이 되길 바랍니다.

참고로: 저는 이 방법을 두 가지 방식으로 시도해 보았으며, 위의 백업 방법을 수행한 후 모든 docker 컨테이너, 이미지 및 /var/discourse 디렉터리를 지웠습니다(매번 완전히 파괴).

각 경우에서, 저는 저장된 docker 이미지를 로드하고 /var/discourse 디렉터리를 tar에서 해제하고 ./launcher start app을 실행하여 Discourse가 완벽하게 시작되도록 했습니다. 그리고 이를 증명하기 위해 UI에서 정상적인 백업을 수행할 수 있었으며, 모든 것이 정상임을 확인했습니다.

이것이 귀하의 질문에 답하는지 확실하지 않습니다(그리고 Postgres 10에서 12로 업그레이드하거나 관련 토론에 참여하지 않았습니다); 하지만 앱을 tar로 백업하고 복원하는 것에 대한 귀하의 질문에 대해서는, 네라고 답할 수 있지만, /var/discourse 디렉터리를 아카이브하는 것뿐만 아니라 이미지를 docker save로 저장해야 합니다.

주요 "주의할 점"은 이미지 저장소 이름과 태그를 올바르게 유지하는 것이며, 그렇게 하면 문제없이 진행될 것입니다.

이것이 귀하의 질문에 조금이나마 도움이 되길 바랍니다:

/var/discourse 앱 폴더 전체를 백업하고 복원하는 방법?

답변은 폴더와 docker 이미지 모두를 아카이브해야 한다는 것입니다(위 예시처럼). 이미지를 백업하기 위해 docker save를 사용하고, 복원하기 위해 docker load를 사용합니다.

이 방법이 공식적으로 지원되지 않는다는 점을 명심하십시오. 하지만 호기심 때문에 시스템 관리자 관점에서 어떻게 해야 하는지 알고 싶었고, 이전에 답변했던 것보다 더 쉬울 것이라는 것을 알게 되었습니다.

참고 1:

/var/discourse/ 전체를 tar로 압축하기 전에 backups/default 디렉터리에서 모든 백업을 (디렉터리 트리에서) 이동시키고, 그 백업들을 (별도로) 보관하는 것이 좋습니다. 그 파일들이 매우 크기 때문이죠…

참고 2:

이 유형의 백업은 지원되지 않으므로 대부분의 Discourse 시스템 관리자에는 권장하지 않습니다. 사용자는 권장(그리고 공식적으로 지원되는) Discourse 백업 및 복구 방법을 따를 것을 권장합니다.

호기심을 유지하세요!

건강히 지내세요.


스크린샷을 포함한 더 자세한 내용은 제 전체 게시글을 참조해 주세요:

훌륭한 접근 방식입니다! 감사합니다!

복원 서버에서 문제가 하나 발생했습니다.

./launcher logs app

2020-06-18 13:33:56.434 UTC [127] FATAL: data directory “/shared/postgres_data” has wrong ownership
2020-06-18 13:33:56.434 UTC [127] HINT: The server must be started by the user that owns the data directory.
./run: 3: echo: echo: I/O error
2020-06-18 13:33:57.448 GMT [128] LOG: skipping missing configuration file “/shared/postgres_data/postgresql.auto.conf”


이는 누락된 tar 옵션 때문일 수 있습니다? 추출 시 -p와 -s를 추가했지만 도움이 되지 않았습니다.

원본 서버 (docker 외부):

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 4096 May 25 13:16 base

원본 서버 (docker 내부 (./launcher enter app)):

ls -la /var/lib/postgresql/10/main/

drwx------ 5 root postgres 4096 May 25 23:28 base


복원 서버 docker 외부:

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 71 May 25 11:16 base

복원 서버 docker 내부:

drwx------ 5 root postgres 41 May 25 23:28 base


./launcher rebuild app를 실행하면 해결되겠지만, 이는 본질적인 문제가 아닙니다.

아무 아이디어가 있으신가요?

복원 과정을 고려해 볼 때, docker save -o /tmp/my.discourse.docker.base.tar discourse/base:2.0.20200512-1735라고 말씀하신 것 같습니다. 어쨌든 잘 설명해 주셨습니다!

하지만 말씀하신 대로, 이는 공식적으로 지원되는 방식이라고 생각되지 않습니다(다만, Discourse 팀이 재빌드 과정에서 1개 이상의 베이스 이미지를 사용하기 시작하는 경우를 제외하면, 오류를 유발할 수 있는 다른 요인은 없다고 생각합니다).

아래 링크에서도 동일한 문제가 있는 것 같습니다:

https://meta.discourse.org/t/postgresql-12-update/151236/298?u=lucasbasquerotto

이 특정 문제에 대한 답변은 FAQ에 아직 없지만, 1명 이상이 이 문제를 겪고 있으므로 discourse 팀이 해결책을 추가할 수 있을 것입니다. The source cluster was not shut down cleanly에 대한 FAQ가 있으며, 이는 귀하의 문제와 관련이 있을 수 있습니다.

docker save를 사용하거나 /var/discourse 전체를 tar+untar하지 않는 방법 중 제가 사용했던 방법은 다음과 같습니다: