여기에 답글을 달아야 할지, 아니면 새 게시물을 작성해야 할지 잘 모르겠습니다: 기능 요청 - '첨부파일 포함’과 '첨부파일 제외’에 대해 별도의 일정 설정.
데이터베이스가 작으므로, 매일 작은 백업, 가능하면 하루에 여러 번 백업이 되었으면 좋겠습니다. 첨부파일은 훨씬 제한적이며, 보통 원본을 다시 찾을 수 있으므로 일주일 치를 잃어도 크게 문제가 되지 않을 것 같습니다. 이렇게 하면 저장소를 과부하 시키지 않으면서도 안전성을 높일 수 있을 것입니다.
소스 코드는 확인해 보지 않았지만, 복원이 별도의 엔티티가 되어야 하거나, 두 소스에 대해 다른 복원 지점을 가질 수 있는 기능이 있어야 하므로 상당한 개편이 필요할 것 같습니다.
이 요청에 대해 일반적으로 권장되는 조치는 외부 도구를 사용하여 다른 데이터베이스 백업을 만드는 것입니다.
업로드를 S3로 이동하면 데이터베이스만 백업하면 되므로 업로드에 대해 걱정할 필요가 없습니다.
상당히 합리적인 의견입니다. 외부 도구를 고려하기 시작하면, 내장된 관리자 콘솔이 어리석은 실수를 방지하도록 (거의) 설계되어 있는 반면, 외부 도구는 그보다 훨씬 더 큰 혼란을 야기할 수 있기 때문에 '외부에서 진짜로 모든 것을 엉망으로 만들 수 있는 방법’이라고 생각하게 됩니다.
지난번에 저를 비롯한 다른 분들이 같은 질문을 했을 때, 답변은 이전과 동일했습니다:
음, 데이터베이스에 대해 하루에 한 번의 백업만으로는 부족하고, 시간당 백업 정도가 적절할 것입니다.
외부 도구로 이 작업을 수행할 수 있다는 점은 맞습니다. 하지만 다른 모든 앱은 기본적으로(네이티브로) 적절한 백업 기능을 제공하는 반면, Discourse만 그렇지 않습니다.
정말 그 이유를 알고 싶습니다:
음, 그리고 항상 세 번째 옵션이 있습니다: Marketplace
WordPress(인기 있는 웹 플랫폼)에서 수많은 백업을 원한다면 돈을 내야 하는 백업 플러그인을 사용해야 하므로, 아마 모든 앱이 기본적으로 그렇게 하는 것은 아닐 것입니다. 적어도 저는 그렇게 하고 있지만, 그 결정을 내린 지 꽤 오래되었기 때문에 잘못된 결정이었을 수도 있습니다.
그 이유는 수많은 백업을 가지고 있는 것이 디스크를 가득 채우는 방법이기 때문입니다. 디스크 공간 부족은 셀프호스팅 사이트가 다운되는 가장 흔한 이유 중 하나이며(저는 이것이 “비싼” 범주에 속한다고 생각합니다). 따라서 수십, 수백 개의 백업을 관리하고 디스크 공간을 관리할 만큼 충분한 기술력을 갖추고 있다면, 아마도 여러 방법 중 하나로 이 문제를 해결할 수 있을 것입니다. 그리고 시간 단위로 백업을 원한다면, 업로드된 파일의 수십, 수백 개 사본이 아니라 데이터베이스 전용 백업이어야 합니다.
따라서 시간 단위 백업은 업로드 파일을 S3에 저장하여 데이터베이스 전용 백업을 수행할 수 있고, 아마도 로컬 디스크에 대해 걱정하지 않도록 그것들을 S3로 푸시할 수 있는 경우에만 의미가 있습니다. 그리고 그렇게 원하는 셀프호스팅 사이트는 꽤 적은 수가 될 것입니다.
만약 모든 것이 그렇게 설정되어 있다면, 시간 단위 데이터베이스 전용 백업을 수행하는 플러그인은 1~2시간의 작업이 될 것이며, 플러그인을 만드는 방법을 몰라서 시간 단위 작업을 만드는 방법을 알아내야 하는 경우라면 2~10시간 정도가 걸릴 것입니다.
맞습니다. WordPress 자체로는 할 수 있는 일이 많지 않습니다. 그래서 플러그인이 이렇게 많은 것이죠 — 좋은 것도 있고 나쁜 것도 있고요.
그건 사실이 아닙니다. 추가 기능만 비용을 청구할 뿐, 백업 자체에는 비용이 들지 않습니다.
물론, 파일이나 시스템 자체를 너무 자주 백업하는 것은 의미가 없습니다. 데이터베이스는 완전히 다른 문제입니다. 트래픽이 많다면 최소 15분 간격으로 백업해야 합니다.
결국 핵심 질문은 단순합니다: 얼마나 많은 콘텐츠를 잃을 수 있는가?
허용할 수 있는 최대 데이터 손실이 이 정도라면, 이렇게 자주 백업을 대신하여 Postgres 복제 솔루션을 사용하는 것을 고려해 볼 수 있습니다.
제가 모르는 다른 데이터가 있는 건가요? 아니면 데이터라는 용어를 시스템, Docker/Discourse/등, 업로드된 파일 등 모든 파일을 포함하는 넓은 의미로 사용하고 계신 건가요?
그 파일들은 쉽게 또는 소액의 비용으로 복원할 수 있습니다 — 물론 업로드된 파일은 예외지만, 그래서 S3를 사용하는 거죠 ;).
아니요, 데이터베이스 데이터를 말하는 거였어요.
그렇다면 규모는 대부분 작지만, 포럼 자체를 기준으로 본다면 가장 큽니다. 그런데 왜인지 다시 이런 이야기로 돌아왔습니다:
여기서 주요 문제가 기술적인 것인지, 아니면 심리적인 것인지 정말 궁금합니다. 아니면 이것이 비즈니스 모델의 일부인지, 백업이 쉬워지고 제대로 작동하게 되면 호스팅 측이 하나의 강점을 잃게 되는 것인지요. 그리고 그런 영업용 피칭이 실제로 존재하는지조차 모르겠습니다. 이미 이전에 요청되었음에도 불구하고, 왜 더 나은 백업이 이렇게 큰 문제인지를 이해하려고 노력하고 있을 뿐입니다.
이 현상 뒤에 전략이나 악의적인 계획이 있다고 의심할 필요는 없습니다. 더 빈번한 백업에 대한 관심이 크지 않다고 생각합니다. 만약 관심이 있었다면, 누군가 이를 위한 플러그인을 개발했을 것입니다. 몇 시간의 작업이면 충분할 테니까요. #marketplace에서 이에 대한 요청이 쏟아지는 것도 보지 못했습니다.
결국 다음과 같이 정리할 수 있습니다:
실제로 백업이 필요한 확률도 매우 낮다는 점을 잊지 마세요. Communiteq의 역사(8년 이상)를 돌아보면, 백업을 복구해야 했던 경우는 단 한 번뿐이었습니다. 그것도 파일 시스템 복구를 몇 시간 기다리기 싫어서 조급한 마음에 진행한 것이었습니다.
*) (클라이언트의 요청에 따른 복구는 제외합니다. 대부분 비프로덕션 포럼에서 변경 사항을 되돌리고 싶어 한 경우였으며, 월간 복구 테스트도 제외합니다)
여기서 검색해 보면, Discourse가 어떤 이유로 인해 충돌(crash)을 일으켜서 백업 복구가 유일한 해결책이었다는 주제를 찾지 못하겠습니다.
하지만 Discourse가 매우 안정적이라 최신 백업이 필요하지 않다는 이야기를 들을 수 있어 좋습니다. 물론 그게 완전히 사실은 아니라는 것을 우리는 알고 있죠.
결국 원점으로 돌아와서 제가 처음에 제기했던 문제로 다시 돌아오게 됩니다:
그리고 바로 그 세 번째 선택지. 제가 사실상 Discourse에 대한 테스트를 여기저기서, 그리고 제 개인적으로 진행 중인 이상, 이렇게 기본적인 기능에 비용을 지불할 의사는 없습니다.
음, 여기서는 팀 측에서 아무런 코멘트도 없이 이야기하고 있네요. 또 
개발 비용은 얼마나 들 거라고 생각하시나요? 가격에 따라, 관심 있으시다면 지금 바로 후원할 의향이 있습니다. 
그 문제는 이미 CDCK에서 다뤘습니다. 답장이 올 때까지 조금만 기다려 주시면 됩니다.
이것이 올바른 방법입니다. 일일 백업이 사용 사례에 충분하지 않다면, 독립된 PostgreSQL 서버로 Discourse 실행하기 문서를 참고하여 자체 PostgreSQL 인스턴스를 실행하고, 백업 및 고가용성(HA)을 원하는 대로 처리하세요.
설정 가능한 정도와 프론트엔드에서 필요한 작업량에 따라 250~500달러 정도라고 생각하고 있습니다. 다만 실제로 어떤 작업이 필요한지 확인해 보지는 않았습니다. @RGJ 님이 더 적은 비용으로 해 주실 수도 있습니다. 그는 종종 얼마나 빠르게 일을 처리할 수 있는지 저를 놀라게 하곤 하니까요.
수정: 아, 이 토픽은 이미 닫혀 있네요. 관심 있으시다면 저에게 연락하시거나 Marketplace 채널에 게시글을 남겨 주세요.