모든 업로드가 S3에 저장되어 있는 한 이는 예상되는 현상입니다. 이 경우 백업 파일은 압축된 데이터베이스 덤프만 포함합니다.
/logs를 확인해 주시겠습니까? 백업과 관련될 수 있는 오류가 있는지 확인해 주세요.
또한 시스템이 실패한 백업에 대해 개인 메시지(PM)를 보냈는지 /u/system/messages/sent를 확인해 주세요. 특정 상황에서 관리자가 해당 PM에 대한 통지를 받지 못하도록 하는 버그가 있었습니다.
수동 백업까지 사라진 점은 다소 우려스럽습니다. maximum_backups를 3으로 설정했기 때문에 어떻게 그렇게 될 수 있는지 정확히 알 수 없습니다. 백업을 이동/삭제하거나, 새로운 파일 확장자(sql.gz 대신 tar.gz)와 호환되지 않는 크론 작업(cronjob)이나 스크립트를 설정해 보셨나요?
백업 파일이 실제로 존재하지 않는 건가요? ls /var/discourse/shared/standalone/backups/default 명령을 실행하면 어떤 결과가 나오나요?
아, “Backup failed” 메시지가 여러 개 있네요. 왜 이들에 대한 알림을 받지 않는 걸까요?
음, 왜 보고로 이 메시지가 안 오는지 모르겠지만, 여기에는 다음과 같은 오류가 나 있습니다:
[2021-04-08 03:35:35] Removing tmp ‘/var/www/discourse/tmp/backups/default/2021-04-08-033313’ directory…
[2021-04-08 03:35:35] Gzipping archive, this may take a while…
[2021-04-08 03:38:49] EXCEPTION: lib/discourse.rb:92:in `exec’: Failed to gzip archive.
gzip: /var/www/discourse/public/backups/default/keyboard-maestro-discourse-2021-04-08-033313-v20201116132948.tar.gz: No space left on device
사실 그것은 외부 스크립트입니다 - 백업을 영구 저장용으로 다른 기계로 복사한 후 서버에 공간을 남기기 위해 삭제합니다(하지만 Apparently 공간이 충분히 남지 않은 것 같습니다).
따라서 남은 질문들은 다음과 같습니다:
왜 이 오류 메시지에 대한 알림을 전혀 받지 못하는 걸까요?
실제 백업이 .tar.gz 파일인 반면, 수동 백업이 .sql.gz 파일인 이유는 무엇인가요(둘 다 로컬에 있는 업로드를 포함해야 합니다)?
왜 수동 백업은 작동하는데 자동 백업은 공간 부족으로 실패하는 걸까요(아마도 관련이 있을 것 같고, 수동 백업이 실제로 업로드를 포함하지 않아 더 작은 크기일 수 있으며, 그렇게 보이지만 적절한 크기처럼 보입니다)?
그리고 가장 명백한 질문 - 서버에 추가 공간을 어떻게 확보할 수 있을까요? [편집: 음, ./launcher cleanup을 실행하니 15GB의 공간이 확보되어 차이를 만들 수 있을 것 같습니다].
음, 이제 문제가 무엇인지는 알았으니, 첫 번째 질문에 대한 답을 정말 알고 싶습니다. 당연히 이 문제에 대해 알았어야 하니까요. 이 메시지는 누구에게 이메일로 보내지거나 누구에게 알림이 가는 건가요? 앞으로 이러한 메시지를 어떻게 알 수 있게 할 수 있을까요?
