에러 코드를 기준으로, 이 문제와 유사한 것 같다고 생각했습니다: Upgrade gone sideways [deprecated Guest Gate plugin]. 그래서 플러그인을 최신 버전으로 업데이트하는 데 집중했습니다. 하지만, 그들이 수동으로 구버전 PSQL을 강제 적용한 문제도 있었을 수 있으며, 구버전 플러그인을 정리하기 전에 그 문제를 먼저 수정한 후(그것이 문제를 제대로 해결했습니다) Upgrade gone sideways [deprecated Guest Gate plugin] - #3 by dylanb
하지만 그 문제를 해결하는 것은 제 능력 범위 밖인 것 같습니다. 
해당 토픽에서 여러분에게 추가적인 힌트를 줄 수 있을까요?
저도 아까 그 부분을 확인해 봤는데, 아쉽게도 도움이 될 만한 내용은 찾지 못했어요.. 그리고 제 포럼 데이터가 지워지지는 않을까 정말 걱정이에요.. 아주, 아주 오래전부터 백업을 한 번도 만들어 본 적이 없어서, 데이터가 손실되면 정말 믿을 수 없을 정도로 마음이 무너질 것 같아요.
계속하기 전에 재빌드 전 버전을 실행하기 위해 기존 컨테이너를 시작하고 백업을 수행해 주시겠습니까?
./launcher start app
불행히도 컨테이너가 더 이상 존재하지 않는 것 같습니다. 제가 시도하던 수정 방법은 도커를 완전히 제거하고 다시 설치하는 것이었는데, 그 결과 기존 컨테이너가 하나도 남지 않았습니다. 그래서 이제 해당 명령을 실행하면 다음과 같은 상태만 남게 됩니다:
이런 글도 찾았습니다: Database system was not properly shut down error when rebuilding - support - Discourse Meta
지금까지 찾아본 모든 정보가 데이터 손실로 귀결되는 것 같아서 정말 우울해지고 있습니다..
1년 전 것이 유일한 백업인 것 같은데, 데이터 손실 없이 이 문제를 해결할 방법을 찾아주시는 분이 있으면 정말 감사하겠습니다.
아마 아무 관련이 없겠지만, 4.15.0-91 커널은 좀 오래되지 않았나요? 약 30개월 정도 된 것 같습니다.
네, 서버를 만든 지 꽤 됐어요 ㅋㅋ 근데 그건 별 상관없을 것 같은데, 그전까지는 잘 작동했으니까요.
대안이 데이터 손상/손실일 수 있다는 점을 고려하면, 오래된 커널과 docker 20.10 사이의 이상한 종속성 문제로 인해 psql이 시작되지 못했다는 사실을 알아차리는 편이 낫다고 생각합니다… 하지만 그게 아주 희박한 가능성이라는 점에는 동의합니다 
그리고 그렇게 된다면 "왜 지금에야?"라는 질문이 따라올 텐데요.
정말 의심스럽네요. 데이터베이스 종료 과정에서 제가 Docker를 멈추고 재설치한 것 같기도 한데, 정확히는 잘 모르겠어요.
/var/discourse/shared/standalone의 내용은 무엇인가요?
ls /var/discourse/shared/standalone 명령을 사용하여 확인해 보세요
다른 볼륨으로 이동했으며, 내용은 아래와 같습니다:
root@discourse:/var/discourse# ls /mnt/volume-2/standalone/ -al
total 64
drwxr-xr-x 16 root root 4096 Feb 5 2021 .
drwxr-xr-x 3 root root 4096 Aug 30 2020 ..
drwxr-xr-x 3 1000 www-data 4096 Aug 30 2020 backups
drwxr-xr-x 10 root root 4096 Nov 20 08:35 letsencrypt
drwxr-xr-x 4 root root 4096 Aug 30 2020 log
drwxr-xr-x 2 systemd-resolve input 4096 Aug 30 2020 postgres_backup
drwx------ 19 systemd-resolve input 4096 Nov 20 12:01 postgres_data
drwx------ 20 uuidd uuidd 4096 Feb 5 2021 postgres_data_old
drwxrwxr-x 5 systemd-resolve input 4096 Nov 20 12:01 postgres_run
drwxr-xr-x 2 messagebus syslog 4096 Nov 20 08:38 redis_data
drwxr-xr-x 2 root root 4096 Dec 1 2020 ssl
drwxr-xr-x 3 root root 4096 Aug 30 2020 standalone
drwxr-xr-x 4 root root 4096 Aug 30 2020 state
drwxr-xr-x 4 1000 www-data 4096 Nov 20 08:36 tmp
drwxr-xr-x 2 root root 4096 Aug 30 2020 uploads
drwxr-xr-x 4 root root 4096 Aug 30 2020 uploads.orig
컨테이너가 없더라도 데이터베이스의 일부 상태가 온전히 남아 있을 가능성이 있습니다. 실험을 하더라도 이 복사본을 안전하게 보관해 두시기 바랍니다.
현재 구성 방식에 따르면, 데이터베이스는 Docker 볼륨에 저장되어 있어 일반적으로 컨테이너 내부에서 접근할 수 있습니다.
컨테이너를 다시 빌드할 수 있다면 다시 접근할 수 있을 수도 있고, 그렇지 않다면 서버에 Postgres를 설치해야 합니다(다만, 시스템이 정상 작동하게 되면 이 설치 내용은 중복이 됩니다).
네, 가장 힘든 부분은 리빌드가 아예 작동하는 것 같아요. 그게 안 되면 사실상 꼼짝없이 되는 거 같네요.
그래도 혹시 몰라서 이 폴더 내용을 로컬 머신에 복사해 두겠습니다.
Postgres 업데이트 실패로 보입니다. @Headless 님, 커맨드 라인을 통해 사이트를 마지막으로 업데이트한 시점이 언제였나요?
업데이트라 하면, 코드를 가져와서 다시 빌드하는 걸 말하는 건가요? 저는 대략 몇 달에 한 번씩 그렇게 하고 있습니다.
최근 백업은 무엇인가요?
ls /var/discourse/shared/standalone/backups ?
이것은 이전에 언급했던 1년 전 백업 파일입니다.
어느 시점에 백업을 꺼버렸으니 제 실수입니다.
이 사이트를 복구하는 일은 꽤 모험적인 로데오가 될 것 같습니다. 이런 복구 작업을 꽤 오래 안 해서 기억이 좀 흐릿하네요. 복구에 관한 지침이 있는 기존 주제를 찾아볼게요.
지원해 주셔서 감사합니다!