새로 설치한 Discourse 인스턴스에서 복원을 시도하고 있는데, CLI에서 다음 오류가 발생합니다:
ERROR: could not extend file "base/16384/17011337": wrote only 4096 of 8192 bytes at block 15860
HINT: Check free disk space.
EXCEPTION: psql failed: HINT: Check free disk space.
복원하려는 백업 파일은 22GB(압축된 gz)이고 서버의 남은 용량은 198GB이므로, 실제로 디스크 공간 문제가 아니라고 생각합니다. 이 오류가 발생하는 이유가 무엇일까요?
압축 해제된 크기에 대해 어떤 정보가 있나요? 또한 이는 인덱스를 고려하지 않은 것이므로, 디스크 용량이 더 큰 서버에서 시도해 볼 수 있습니다.
디스크 파티션도 확인해 보실 수 있습니다. 서버에 198GB의 여유 공간이 있는 것은 맞을 수 있지만, 서버에는 여러 개의 디스크 파티션이 있을 수 있습니다. df 명령어의 출력을 공유해 주시면 어떨까요?
@Ghan 님
명령줄에서 복원을 시작했나요, 아니면 “docker manager” UI에서 시작했나요?
두 가지 방식으로 시도해 보았지만, 최근에는 CLI에서 사용했습니다. 디스크 공간을 늘린 후 가져오기가 진행되는 동안 사용량을 모니터링해 보겠습니다.
50GB를 추가했고, 성공적으로 완료되었습니다. 데이터베이스로서는 상당한 용량입니다.
복원 프로세스가 가져오기(import)보다 추가적인 인덱스를 생성하나요?
이것은 포럼 콘텐츠를 저장합니다. 1GB 규모의 Discourse 인스턴스도 있고 500GB 규모의 인스턴스도 있으며, 활동량에 따라 다릅니다 
PostgreSQL 13 업데이트 토픽에서 각 테이블의 크기를 확인할 수 있는 쿼리가 있습니다. 실행해 보시고 결과를 여기에 올려 주시겠어요?
콘텐츠가 많다는 건 알고 있습니다. 그런데 백업과 복구를 진행한 것만으로 필요한 공간이 갑자기 크게 늘어난 것 같습니다. 백업 전에는 100GB 이상의 여유 공간이 있었기 때문에 복구에 문제가 없을 거라고 생각했지만, 복구 작업에는 예상보다 훨씬 더 많은 공간이 필요했습니다. 결과적으로 아주 조금 부족했던 것 같습니다.
데이터베이스에서 가장 큰 객체 상위 20개를 보여주는 쿼리를 실행해 보고 있는데, 이미 1시간 정도가 지났고 언제까지 실행될지 감이 잡히지 않습니다.
스키마 백업과 복원이 여전히 남아 있는지 확인해 보세요. 복원/백업이 치명적으로 실패하는 경우(예: 공간 부족)에는 해당 항목이 남아 있을 수 있습니다. 매주 실행되어 이를 정리하는 백그라운드 작업이 있지만, 더 빨리 실행하는 것이 좋을 수 있습니다.
/sidekiq/scheduler로 이동하여 Jobs::DropBackupSchema를 검색한 후 트리거를 클릭하세요.
완전 백업이 있으면 총 3개의 사본이 있게 됩니다. 완전 백업, 그 안에 포함된 데이터베이스 덤프, 그리고 복원된 데이터베이스, 그리고 시작 시점에 이미 존재하던 데이터베이스까지 포함됩니다.
