Amazon S3에 업로드되고 있음에도 불구하고 내 백업 파일이 /var/discourse/shared/standalone/backups/default에 계속 쌓이고 있습니다.
제 Discourse 설정은 다음과 같습니다:
Discourse 백업:
S3 버킷에 있는 백업:
그리고 /var/discourse/shared/standalone/backups/default의 내용:
이 문제는 오랫동안 지속되어 왔습니다. 이러한 잔여 파일을 삭제하기 위해 달력에 월간 알림을 설정해 두고 있습니다. 백업 로그는 비어 있으며 "No logs yet…"라고 표시되고, Amazon S3 관련 문제를 가리키는 에러 로그도 없습니다.
Discourse는 정기적으로 업데이트되고 있으며 현재 버전은 2.9.0.beta14입니다.
이건 표준 설치인 거죠? 업로드 중에 OS(또는 기타 요소)가 백업 프로세스를 종료할 가능성이 있을까요? 왜냐하면 백업 실패가 발생하더라도 프로세스가 끝날 때 로컬 파일은 삭제되어야 하니까요.
네, DigitalOcean 드롭렛에 표준 설치되어 있으며, Ubuntu 16.04.7 LTS를 사용 중입니다. 관련 로그는 어디에 있을까요?
일부러 S3 호환 서비스를 잠시 사용했는데, 간헐적으로 백업 파일이 로컬 드라이브에 남아 있는 경우가 있었습니다.
/var/discourse/shared/standalone/logs/rails/production.log 파일을 확인해 보세요. 단순히 커맨드 라인으로 백업을 실행한 후, 해당 동작이 나타나는지 확인해 보시면 됩니다.
프로덕션 로그는 지난 1주치만 보관되므로, 오래된 “삭제되지 않은” 백업은 해당 범위에 포함되지 않습니다. 다만 향후 백업은 계속 주시하겠습니다. 백업 오류 항목은 11/30 로그에 있는 아래 항목 하나뿐이었습니다:
Started GET "/.env.backup" for 3.236.147.46 at 2022-11-29 19:15:57 +0000
ActionController::RoutingError (No route matches [GET] "/.env.backup")
/var/discourse/shared/standalone/backups/default 디렉토리에 삭제되지 않은 새로운 백업이 보이지만, production.log에는 아무것도 없습니다. production_errors.log에도 아무것도 없습니다. 다른 곳은 어디를 살펴볼 수 있을까요?
P.S. CLI에서 백업을 실행했는데 백업이 성공적으로 제거되었습니다. 오류를 발생시킬 수 있는지 확인하기 위해 몇 번 더 시도해 보겠습니다.
CLI를 통해 삭제되지 않은 로컬 백업을 재현하는 데 성공하지 못했지만, 주간 1~2회 밤 시간대 백업 중에 계속 발생하고 있습니다. 또한 production.log에 백업 로그 출력이 전혀 보이지 않습니다. @pfaffman 님, 로그가 그곳에 기록되는 것이 맞는지 확인해 주시겠습니까?
그렇게 되어 있을 것 같습니다. 비슷한 문제를 some other S3 service에서 겪었을 때, Discourse나 해당 서비스 어디에서도 오류를 찾을 수 없었습니다. 결국 포기하고 다른 것으로 전환했습니다. 하지만 AWS, S3, 즉 정통 제품을 사용하시니 꽤 놀랍네요.
다음과 같이 검색해 보았지만:
grep -r "Output file is stored on S3" /var/discourse
해당 문구가 CLI 백업 출력의 마지막 줄이기 때문에, 아무것도 찾지 못했습니다.
호스트 OS의 자동 업데이트로 인해 서버가 재부팅될 가능성은 없나요? S3 업로드가 진행 중일 때 이런 일이 발생할 수 있습니다. OS 로그에 관련 정보가 있는지 확인해 보세요. backup_time_of_day 사이트 설정을 기본값이나 다른 시간으로 초기화해 보고 문제가 사라지는지 확인해 보시기 바랍니다.
아니요, 현재 가동 시간(Uptime)은 36일입니다. DigitalOcean 드롭렛 백업이 동시에 실행되면서 문제가 발생한 것 같다고 의심했지만, 해당 백업은 주 1회 실행되는 반면 제가 삭제하지 않은 백업은 그보다 더 자주 생성되고 있습니다.
다른 backup_time_of_day 값을 시도해 볼 예정입니다. 원래 2:00 UTC로 설정되어 있었으니, 기본값인 3:30 UTC로 변경했을 때 차이가 있을지 지켜보겠습니다.
오! 정말 좋은 지적입니다. 그게 원인이겠네요. 아마도 그게 맞을 것 같아요. 자정 무렵은 백업과 재부팅 모두에 적합한 시간이지요. 다른 서비스로 변경했을 때 문제가 사라진 이유는 정확히 설명되지 않지만, 운이 좋아졌거나 변경한 서비스가 더 빠르거나 하는 이유일 수도 있겠네요.
아, 그래요. 실망입니다. 
16일 후, 이것이 해결책인 것으로 보입니다. 더 이상 삭제되지 않은 백업이 없습니다. 충돌을 일으킨 원인이 무엇이었는지는 모르겠지만, 이제 더 이상 중요한 문제가 아닙니다.