Discourse 포럼을 항상 복구할 수 있도록 보장하는 가장 기본적이면서도 확실한 방법은 무엇인가요?

수년간 저는 친구들이 직접 포럼을 호스팅하는 일을 도왔습니다.

저는 그들에게 Hetzner 서버를 임대하고 Discourse에서 자동 백업을 설정하도록 안내했으며, rclone과 cron 작업을 통해 백업을 제 Google Drive에 동기화했습니다. 각 포럼의 관리자는 제 Drive에서 자신만의 백업에 접근할 수 있습니다. 시스템 관리자가 아닌 저로서는 상상할 수 있는 가장 단순하고 안전한 방법입니다.

몇 차례 rClone에서 토큰이 갱신되지 않는 문제를 발견했습니다(적어도 하나의 인스턴스에서). 그래서 재설정해야 했습니다. 동기화가 실패해도 어떤 알림도 받지 않기 때문에, 저는 가끔씩 Drive를 직접 확인하여 마지막 백업이 최신 상태인지 수동으로 점검합니다.

만약 여러분이 자원봉사로서 누군가나 단체가 포럼을 호스팅하도록 돕는다면, 포럼이 어떤 이유로든 무너졌을 때 안전하게 복구할 수 있도록 백업이 항상 어딘가에 존재하도록 보장하기 위해 어떤 솔루션을 설정하시겠습니까?

나는 제한된 계정을 통해 ssh로 rsync를 사용하여 백업을 가져오고, 이를 cron 작업으로 실행한다. 사실 나는 직접 하지 않지만, 내 중 하나인 모드가 그렇게 하고 있다. 나는 업데이트를 수행할 때 백업을 생성하고 다운로드한다. 따라서 한 경우(모드의 cron 작업)에는 포럼 활동의 며칠치가 손실될 수 있고, 다른 경우(내 수동 백업)에는 한 달 이상 손실될 수 있다.

나도 내 자신의 crontab을 설정해야 할 것 같다. 또한 백업 빈도를 높일 수도 있다 - 현재 2일로 설정되어 있다.

두 경우 모두에서 우리는 각자의 시스템에 대해 상당히 유능한 관리자여야 한다. 우리 둘 다 다운로드한 사본과 자체 백업, 그리고 서버 자체를 모두 잃어야만 포럼이 완전히 손실된다.

수정: 좋은 지적이다. 프로세스가 정상적으로 작동하는지 확인할 수 있는 어떤 긍정적 확인 메커니즘이 필요하며, 다운로드한 백업이 정상적인지에 대해 아무리 얕은 수준이라도 어떤 개념이 있어야 한다.

도메인에 대해서는 특별한 주의를 기울이지 않았다: 이상적으로는 도메인도 이중 관리와 공동 소유의 어떤 형태를 가져야 한다. 만약 우리가 통제력을 잃게 된다면, 포럼은 새로운 도메인에서 다시 등장해야 할 것이다. 이메일을 통해 멤버들에게 다이제스트와 알림을 보낼 수 있으므로, 약간의 신뢰만 있다면 멤버들이 다시 가입할 수 있을 것이다.

백업에는 S3를 권장합니다. 안전을 원하신다면 포럼을 매일 백업하세요. 더 확실한 안전을 원하신다면 VPS도 백업하세요.

다음과 같은 자료도 있습니다:

음, 저는 데이터베이스를 매시간 백업하고 있어요 :man_shrugging: 이커머스도 같은 원리인데, 복원할 수 있고/원하는 가장 긴 시간 범위를 고려해야 하거든요.

restic를 사용하여 S3 및 외장 드라이브로 백업하기

동의합니다. S3 설정이 포함된 YML 파일과 백업이 S3에 저장되어 있다면, 새 서버에 포럼을 복원하는 데 필요한 것은 YML 파일뿐입니다. 이는 디스크가 백업으로 가득 차는 문제를 피할 수 있는 추가적인 장점도 있습니다.

주의할 점: S3 버킷 비용과 VM 비용을 모두 납부해야 한다는 점을 잊지 말아야 합니다. 아마도 Cloudflare의 것이 가장 저렴할 것 같습니다.

한 사용자의 AWS 계정 관리 권한이 상실되어 모든 이미지를 잃어버린 사례가 있었습니다. 따라서 단순히 청구서를 납부하는 것을 잊지 않는 것조차 과소평가할 수 없는 비용입니다.

정말 그렇습니다 - 데이터의 모든 사본을 하나의 제공업체에만 두지 마세요.

암호화된 사본을 3개씩 보관하는 걸 선호합니다. 하나는 호스트에, 다른 하나는 클라우드(S3 호환)에, 마지막 하나는 광학 디스크나 USB 드라이브에 보관하죠.

분산형 스토리지에 백업할 계획이라, 현재 이용 가능한 옵션들의 신뢰성도 함께 조사하고 있습니다.

현재 저는 매일 한 번씩 백업을 실행하고 업로드하고 있습니다.
데이터베이스는 Discourse의 내장 백업 기능을 통해 백업하며, 원본 이미지는 restic을 사용하여 매일 증분 백업을 수행합니다.
모두 클라우드 저장소(웹디스크)에 업로드하고 있지만, 현재 단점은 하나의 웹디스크에만 업로드되고 있다는 점입니다. 향후에는 여러 웹디스크에 업로드할 수 있도록 개선하는 것이 좋습니다.

오프사이트 백업과 오브젝트 스토리지를 사용하세요. 저는 Cloudflare R2(S3 호환)를 사용하고 있으며, 여러 번 다른 서버로 복원해 보았습니다. 관리와 복구가 쉽습니다. 또한, 이중 컨테이너 빌드를 사용하세요.

이러한 유형의 질문에 유용한 전략은 위협 모델(threat model)을 고려하는 것입니다.

이미 몇 가지 사례를 살펴보았습니다.

  • 서버가 있는 건물이 화재로 소실되는 경우
  • 서비스 제공업체의 계정에 대한 통제를 잃는 경우
  • 도메인을 관리하는 사람이 영구적으로 연락이 두절되는 경우
  • 이메일 계정에 대한 접근 권한을 잃는 경우
  • 어떤 문제가 발생하여 백업이 최신 상태가 아닌 것으로 드러나는 경우
  • 기술적인 이유로 백업을 복원할 수 없는 경우
  • 포럼 관리자가 영구적으로 연락이 두절되거나 협조하지 않는 경우

요약하면 다음과 같습니다.

  • 건물은 화재나 홍수로 파괴될 수 있습니다.
  • 사람들은 사이가 틀어지거나 사망할 수 있습니다.
  • 기업은 정책을 변경하고 자의적인 결정을 내릴 수 있습니다.
  • 데이터의 단일 사본은 불량 상태이거나 접근할 수 없게 될 수 있습니다.

각 사람, 각 기업, 각 사본에 대해 이 항목들을 하나씩 검토하고, 자신의 취약점이 어떤 모습인지 살펴보세요.

기술적인 측면이 부담되지 않는다면 git-annex를 살펴보실 수 있습니다.