Discourse가 S3 백업 유지 개수를 준수하지 않음

비슷한 문제가 우리에게 다시 발생했습니다. 설정값이 3개로 제한되어 있음에도 불구하고 로컬 백업이 수십 개(각각 1.6GB) 존재하는 것을 방금 발견했습니다. 이 설정은 수년간 정상적으로 작동해 왔지만, 오래전에 비슷한 문제가 발생한 적이 한 번 있었다는 기억은 나네요.

  • 백업이 성공적으로 완료됩니다
  • S3 업로드도 성공적으로 수행됩니다
  • stable 브랜치를 사용 중입니다. 방금 2.3.7로 업그레이드하고 재부팅했습니다.

적절한 시점에 더 자세히 조사해야 합니다.

@rizka 님에게 알림을 보냅니다.

업데이트:

이 문제는 9월 11일에 시작되었습니다. 해당 날짜는 우리의 서비스 중단이나 사이트와 관련하여 우리가 수행한 작업과는 일치하지 않습니다.

업데이트:

이것은 고립된 사례가 아닌 것 같습니다. 제 다른 작은 샌드박스 인스턴스에서도 같은 문제가 발생하는 것으로 보입니다. 이 인스턴스는 완전히 다른 인프라(Digital Ocean)에 호스팅되어 있습니다. 여기에서는 9월 16일 이후로 백업이 삭제되지 않고 있습니다. 여기에서도 업로드는 성공적으로 수행되고 있습니다.

음… 이제 보니 이건 완전히 내 실수인 것 같네요. 현재 백업 관리 방식이 어떻게 변경되었는지 완전히 놓치고 있었습니다. 그러면 Discourse가 이제 오래된 백업을 버킷 규칙으로 정리할 필요 없이 S3 백업을 직접 관리하고 삭제하는 건가요? 백업이 로컬 디스크 공간을 차지하지 않도록 하기 위해 값을 30으로 늘리겠습니다.

다만 S3 버킷에 저장된 백업 개수가 설정값인 3과 일치하지 않았습니다.

자체 호스팅 인스턴스에서 AWS S3 백업은 문제가 없습니다:

현재 Discourse의 동작에 맞게 백업 및 버킷 규칙을 적절한 값으로 재설정했습니다. 앞서 말씀드린 것처럼, 이전 백업 로직에 따라 백업 수를 3으로 설정해 두었었는데, 이제 30으로 변경했습니다.

이 스레드를 열어 두어 주시고, 30일 후 Discourse가 새로 정의된 값을 올바르게 준수하는지 확인한 후 다시 보고드리겠습니다.

이 이슈를 잊고 있었는데, 이제 확인해 보았습니다. 설정값은 30으로 되어 있는데, S3에 백업이 97개나 저장되어 있습니다.

아직 2.3 브랜치를 실행 중이며, 곧 2.4로 업데이트할 예정입니다.

궁금해서요, 결국 알아냈나요?

아, 이건 오래된 이야기입니다. 어떻게든 해결되었을 것 같은 느낌이 드는데, 우리가 CDCK SaaS를 몇 년째 사용해 오고 있어서 이 문제에 대해선 더 이상 명확한 기억이 없습니다.

이 문제가 여전히 남아 있다면 다른 셀프호스터가 보고했을 것 같네요?

저도 방금 정확히 같은 문제를 겪었고, 지난 10분 동안 원인이 s3_disable_cleanup이 somehow 활성화되어 있었다는 것을 알아냈습니다. s3 업로드에만 해당되고 백업에는 해당하지 않는다고 생각했지만, 그건 틀렸습니다.