결국 문제의 원인이 몇 년 전 S3를 처음 설정하려고 했을 때 데이터베이스에서 enable_s3_uploads를 설정한 것임이 확인되었습니다. 이 설정은 S3에 업로드를 시도하지만 충분한 정보가 없어 복원이 작동하지 않는 원인이 됩니다. (아쉬운 점은 멀티사이트/S3 인스턴스를 복원할 때 일부 파일이 "S3로 마이그레이션되지 않았다"는 이유로 실패한다는 것입니다.)
UX에서 S3 업로드 설정을 모두 숨기는 것이 합리적인지 궁금합니다. UX에서 이 설정을 변경하는 것에서 좋은 결과가 나올 것이라고는 생각하지 않습니다. 하지만 데이터베이스에서 S3 업로드를 설정하는 것은 유용할 수도 있겠네요. . . . 어쩌면.
표준 설치로 복원된 인스턴스는 업로드를 표시하지 못하는데, 그 이유는 다음과 같은 처리를 하고 있기 때문입니다:
Started GET "/uploads/short-url/puhaSNHeEy1S2knGFQIAZ8lprRy.pdf" for 68.11.35.109 at 2022-01-25 19:48:06 +0000
Processing by UploadsController#show_short as PDF
Parameters: {"base62"=>"puhaSNHeEy1S2knGFQIAZ8lprRy", "extension"=>"pdf"}
Sent file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830b.pdf (4.4ms)
Completed 500 Internal Server Error in 130ms (ActiveRecord: 0.0ms | Allocations: 10019)
ActionController::MissingFile (Cannot read file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830.pdf)
시스템이 찾고 있는 경로는 /var/www/discourse/public/uploads/default/original/1X/가 아니라 /var/www/discourse/public/default/original/1X/입니다.
… . .
그리고 이것은 S3 버킷 참조를 수정하려고 시도하면서 리맵을 수행한 결과, 로컬 URL의 경로가 깨져서 발생한 것입니다.
이것은 너무 세부적인 내용이라 다른 사람들에게 유용하지 않을 수도 있다고 생각합니다. 그래도 UX에서 S3 업로드 변수를 숨기는 것이 좋은 아이디어라고 여전히 생각합니다.