하루에 백업 1번만 하는 것은 너무 위험하지 않나요? 서버에 문제가 발생했는데 마지막 백업이 어젯치면 어떻게 해야 합니까? 어제와 오늘 사이에 가입한 사용자는 더 이상 가입되지 않은 상태가 되는 건가요? 백업을 더 자주, 예를 들어 1시간마다 하는 것이 더 좋다고 생각합니다. 그런데 백업을 만들기 전에 사이트를 읽기 전용으로 설정해야 하는 건가요? 미리 감사드립니다!
다시 한번 이 의견에 동의합니다. Discourse는 하루에 한 번만 데이터베이스 백업을 자동화할 수 있는 유일한 동적 시스템입니다.
코어에서 이 부분이 조만간 변경될 것으로 기대하지 않습니다. 일주일에 한 번보다 더 자주 기본값을 변경하는 문제에 대해 대화를 나눈 적이 있지만, 이는 이루어지지 않을 것입니다.
압축할 수 없는 업로드 파일의 수많은 사본을 모든 전체 백업에 유지할 이유는 없으므로, 몇 시간 간격으로 데이터베이스만 백업할 수 있는 사이트 설정을 추가하는 플러그인이 좋은 해결책이 될 수 있다고 생각합니다. 관심이 있으시면 개인 메시지를 보내거나 마켓플레이스에서 질문해 주세요.
더 나은 재해 복구(disaster recovery)가 필요하시다면, Running Discourse with a separate PostgreSQL server를 참고하여 PostgreSQL을 직접 운영하시길 권장합니다. 이렇게 하면 라이브 동기화 리플리카, 특정 시점 복구(point-in-time recovery), 더 잦은 백업 등 필요한 정확한 고가용성(high availability) 설정을 직접 제어할 수 있습니다.
이 정책의 이유가 무엇인지 여쭤봐도 될까요? 기술적인 이유인가요, 아니면 등급에 따른 차별인가요? 백업 간격이 24시간이면 트래픽이 많은 포럼에서는 상당히 치명적인 문제입니다. 아니면 이 서비스를 유료 고객에게만 제공하는 건가요?
Discourse를 별도의 PostgreSQL 서버에서 실행하면 다른 서버에 있기 때문에 속도가 느려지나요?
물론, 그것은 하나의 해결책입니다. 다만 앱 사이에서는 꽤 드문 해결책이긴 합니다. PHP/MySQL 환경에서는 cron을 이용해 데이터베이스를 백업하는 것이 정말로 쉬울 수 있지만, 다시 말하지만 그 환경에서는 플러그인이 있든 없든 모든 앱이 스스로 이를 수행할 수 있습니다.
네, 저는 평균적인 일반 사용자보다 조금 더 많은 지식을 가지고 있지만 
도커, 레일스 등이 어떻게 작동하는지에 대한 이해는 매우 얕습니다. 그리고 일반적인 작업이 거의 불가능에 가까운 상황은 정말로 이해하기 어렵습니다. 물론 제 한계 때문일 수도 있지만, 이런 의문을 가지는 사람이 저만은 아니라고 생각합니다.
음. 가까운 미래나 중기적인 미래에 데이터베이스 백업을 쉽게 얻을 수 없다는 것은 알겠습니다.
PostgreSQL 백업도 cron으로 설정할 수 있습니다. 여기서 특별한 차이가 없습니다.
실질적으로 의미 있는 수준에서는 아닙니다. 이 서버를 포함해 우리가 호스팅하는 모든 Discourse 인스턴스는 전용 서버에 있는 데이터베이스를 사용합니다.
더 잘 이해하기 위해 두 가지만 여쭤볼게요.
- 모든 것을 복원하려면 데이터베이스만 있으면 되는 거죠? 설정에서 매일 수행되는 백업은 데이터베이스만 백업하나요?
- 데이터베이스 백업을 수행할 때 포럼을 읽기 전용 모드로 설정해야 하나요? 아니면 아무 때나 문제없이 수행할 수 있나요?
미리 감사드립니다!
설정은 데이터베이스에 저장됩니다.
기술적으로는 업로드 폴더와 app.yml 사이트 정의 파일도 백업하는 것이 좋습니다. 하지만 보통 app.yml은 소스 제어에 두고, 업로드는 객체 저장소 서비스(object storage service)에 저장함으로써 이를 처리합니다.
읽기 전용 모드로 설정할 필요는 없습니다.
즉, 데이터베이스를 별도의 서버에 두고 매시간 백업한다고 가정해 보겠습니다. 관리자 패널 설정에서 파일만 백업하도록 하면, app.yml 파일과 uploads 폴더가 포함된 파일만 백업되고 데이터베이스는 백업되지 않는 것이 맞나요? @Falco
백업에는 데이터베이스와 업로드 파일(S3에 저장되지 않은 경우)이 포함됩니다. app.yml은 Discourse가 이를 읽을 수 없으므로 백업에 포함되지 않습니다.
대부분의 사용자에게 권장하는 방법은 백업을 S3에 저장하고, app.yml은 비상 시 접근할 수 있는 위치에 보관하는 것입니다. 이렇게 하면 app.yml을 사용하여 새 컨테이너를 빌드하고, 명령줄에서 복원할 수 있습니다. 하지만 Postgres를 다른 도구로 백업/복원하고, 이미지도 S3에 저장(또는 다른 방식으로 백업)할 기술적 역량이 있다면, 컨테이너를 다시 빌드하면 바로 복구할 수 있습니다.
또는 여러 Postgres 서버를 지속적으로 미러링하고, 프라이머리가 다운되면 자동으로 백업 서버로 전환되도록 구성할 수도 있습니다.
Discourse가 제공하는 것보다 더 자주 백업을 수행하는 방법은 수없이 많습니다. 더 잦은 백업이 필요하면 다른 방식으로 수행해야 합니다.
여기서 또 하나 짚어볼 점은 리스크와 유지보수입니다. 표준(Out of the box) 데일리 솔루션을 사용하는 경우, 직접 설정하는 것보다 백업 솔루션으로서 더 견고하고 신뢰할 가능성이 높습니다. 만약 직접 설정한 솔루션에서 문제가 발생했는데, 그 사실을 너무 늦게 알아차리게 된다면 어떻게 될까요? 표준 솔루션의 경우 적어도 수백 개의 사이트가 매일 이를 테스트하고 있기 때문에 이러한 위험을 줄일 수 있습니다.
4년 동안 여러 사이트에서 단 한 번도 손상(corruption) 사례가 없었기 때문에, 백업이 실제로 필요한 상황이 발생할 리스크 자체도 낮습니다…
다른 분들이 더 큰 리스크를 언급할 수도 있지만, 아마도 가장 큰 리스크는 서버 용량 부족으로 인한 문제일 것입니다. 따라서 디스크 공간을 주시하고, 알림을 설정해 두는 것이 좋습니다.
제가 이해한 바로는, 가장 좋은 방법은 모든 것을 따로 유지하는 것 같습니다.
Discourse를 실행하는 메인 서버, 그리고 PostgreSQL과 업로드를 위한 S3(또는 기타 객체 저장소 서비스)를 위한 서버를 별도로 두는 방식입니다.
app.yml 파일은 자주 변경되지 않는 것 같으니, 한 번만 저장해 두면 됩니다. 아니면 한 달에 몇 번 정도만 저장하면 될 것입니다.
이렇게 하면 파일을 더 체계적인 방식으로 백업할 수 있습니다.
그렇다면, 코어에 매일 여러 번 백업하는 기능을 구현하지 않은 선택이 합리적이라고 생각합니다. 반면, 복잡한 요구 사항이 있는 사용자들은 그러한 특별한 구성을 직접 수행할 것입니다. 결국 어딘가에 app.yml을 저장해 두고 재설치를 한 다음, 데이터베이스와 업로드 데이터를 위한 S3에 다시 연결하면 됩니다. 백업은 두 서버에 각각 저장되므로, 제 입장에서는 관리하기가 쉽습니다. 매우 공정한 해결책이라고 생각합니다.
설명해 주셔서 모두 감사합니다.
여기 또 다른 스레드가 있습니다: Configure automatic backups for Discourse - #113 by Tris20
@pfaffman 님은 해당 스레드에서 링크와 함께 몇 가지 권장 사항을 제시했습니다. 이를 통해 더 자주 백업을 예약하는 방법으로 커맨드 라인을 알게 되었고, 제 경우에는 꽤 합리적인 해결책이라고 생각합니다:
참고로 이 해결책을 사용하면 Python 스크립트로 모든 것을 결합하여 yaml 파일 등의 복사도 동시에 예약할 수 있습니다.