데이터를 아무것도 잃지 않는다는 점에서는 제가 좀 "통제광"에 가깝습니다. 매일 백업만 한다는 걸 보면 서버에 문제가 생겨 갑자기 매우 중요할 수 있는 하루치 데이터가 사라질 수 있다는 불안감이 항상 듭니다.
너무 기술적인 내용으로 넘어가지 않도록 하겠습니다. 저는 전문가가 아니기 때문입니다. 게시되거나 추가된 내용이 다른 서버로 실시간 복제되는 시스템이 가능할까요? 소셜 미디어 플랫폼에서 콘텐츠를 게시할 때 이렇게 작동한다고 생각합니다.
Discourse에서 이것이 불가능하다면, 시간 단위 백업이 조금 더 안전하지 않을까요? 해당 옵션을 찾을 수 없습니다. 최소 1(일일) 또는 0(비활성화)까지만 설정 가능한 것 같습니다.
여러분들은 이 문제를 어떻게 처리하시나요?
좋은 플랫폼의 좋은 VPS라면 문제가 생기는 일은 거의 없습니다. 특히 업그레이드 사이에 발생하는 일은 더욱 그렇습니다.
저는 포럼을 운영한 지 거의 8년째인데, 데이터 손실은 단 한 번도 없었습니다.
일일 배치 프로세스는 대부분의 셀프 호스터들을 위한 절충안으로 설계되었습니다.
상당히 단순한 시스템이며, 많은 공간이나 처리 성능을 요구하지도 않습니다.
대부분의 사용자에게는 더 자주 실행할 가치가 있다고 상상하기 어렵습니다.
저는 온라인 장애로 인해 백업을 사용한 적이 없습니다. 서버 마이그레이션 시에만 사용했죠. 필요할 때 말입니다(작은 서버를 벗어나게 되었을 때!)
경험은 사람마다 다를 수 있습니다(YMMV).
하지만 더 자주 백업하는 설정이 필요하다고 생각한다면 … 설정을 사용자 정의할 준비를 하고, 그 사용자 정의를 유지 관리할 준비도 해야 합니다(이는 어떻게 하는지 배우거나, 도움을 줄 사람을 고용하는 것을 포함합니다).
백업과 복제(replication)는 두 가지 다른 개념입니다.
백업은 특정 시점의 데이터 스냅샷을 제공합니다. 즉, 복구 포인트를 제공합니다.
복제는 모든 작업을 다른 시스템으로 분산시켜 데이터를 한 곳 이상에서 보유할 수 있도록 하는 것입니다. 삭제 작업도 복제됩니다.
정말 장애 허용(fault tolerance)을 원한다면, 이 두 가지를 모두 갖추어야 합니다. (그리고 더 많은 것이 필요할 수 있습니다…)
따라서 복제는 현재 데이터를 여러 위치에 두는 문제만 해결합니다. 백업은 시스템을 특정 시점으로 복구하는 방법을 제공합니다.
Discourse는 저장을 위해 두 가지 메커니즘을 사용합니다:
PostgreSQL 데이터베이스에 저장된 데이터를 백업하고/또는 복제하려면, 이를 수행하는 방법에 대한 PostgreSQL 문서를 확인하세요. 백업에 관하여 및 복제.
첨부 파일은 조금 더 까다롭습니다. S3에 저장하는 경우 S3 백업을 사용할 수 있습니다. 로컬에 저장된 파일의 경우 다양한 로컬 시스템 옵션을 사용할 수 있습니다.
데이터 양에 따라 전체 백업을 생성하는 것은 무거운 작업입니다. 따라서 이를 더 자주 수행하기는 어렵습니다. Discourse의 표준 백업 절차는 전체 백업을 생성하는 것입니다. 데이터 손실 위험을 줄이고 싶다면 다른 옵션을 찾아야 합니다.
한 가지 옵션은 호스팅 서비스에서 제공될 수 있습니다: 볼륨 스냅샷. 이는 볼륨에 저장된 데이터의 “즉시” 복사본을 만드는 방법을 제공합니다. 이를 통해 볼륨을 해당 시점으로 복구할 수 있습니다. 사용 중인 파일 시스템에 따라 OS 내에서 볼륨 스냅샷이 제공될 수도 있습니다. (예: btrfs는 이를 지원합니다.)
이 외에도 PostgreSQL 문서에는 데이터베이스의 더 연속적인 백업을 생성하여 데이터베이스의 뛰어난 시점 복구(point-in-time-recovery)를 가능하게 하는 내용이 포함되어 있습니다. (백업을 오프사이트로 전송하는 것을 잊지 마세요.) 이는 전체 백업보다 훨씬 빠릅니다.
더 세밀한 첨부 파일 백업을 위해 전체+차등 백업을 관리할 수 있는 다양한 백업 도구를 사용할 수 있습니다. 예를 들어 duplicity를 사용할 수 있습니다. 또는 rsync(삭제 없이)를 사용할 수도 있습니다. 스냅샷 사이에서는 여전히 파일을 잃을 수 있습니다. 삭제 없이 S3를 사용하는 것이 더 안전할 수 있으며, 파일이 이미 다른 시스템에 있기 때문입니다.
결론적으로, Discourse의 표준 백업 메커니즘은 더 빈번한 백업 일정에 적합하지 않습니다. 더 많은 백업을 원한다면, 표준 PostgreSQL 백업/복제 기능, S3, 볼륨 스냅샷 등의 조합을 사용하세요.
제 사이트에서는 정기적인 백업에 Discourse의 백업 시스템을 사용하지 않습니다. 여전히 일일 백업을 유지하지만, pg_dumps와 duplicity 설정(backupninja를 통해 조정)의 조합을 사용합니다.
4시간마다 데이터베이스 백업을 수행합니다. 이는 소실될 수 있는 게시물에 대해 제가 감당할 수 있는 시간 범위입니다. 비교하자면, 제 이커머스 시스템은 5분마다 백업을 수행합니다.
하루 한 번은 충분하지 않습니다. 최대 24시간 분량의 손실된 주제/게시물은 너무 큰 손실입니다.
얼마나 많은 콘텐츠를 잃을 수 있는지에 관한 문제입니다. 조용한 포럼이라면 며칠에 한 번 백업해도 문제가 되지 않겠지만, 매우 활발한 포럼에서는 1시간만 지나도 상당한 손실로 느껴질 수 있습니다. 하지만 실패할 가능성의 희소성도 고려해야 합니다. 예를 들어, 1년에 한 번 1시간 치의 게시글을 잃는다면 그것이 매우 큰 문제가 될까요? 10년에 한 번이라면요? 각자 위험에 대한 견해가 다릅니다.
0은 백업을 비활성화합니다. 이 설정은 단순히 백업 사이의 일 수를 결정합니다.
일일 백업이 충분하지 않다면 @Jagster 님의 맞춤형 고빈도 DB 백업이 더 적합한 솔루션일 것입니다.
네, 저는 AI가 사람들에게 얼마나 위험하게 잘못된 조언을 하는지 강조하고 싶었을 뿐입니다.
만약 누군가가 그렇게 지시받았다고 생각하고 실제로 그렇게 적용한다면 어떻게 될까요? 
Staging/Test server ignored the environment variable - #2 by RGJ 가져온 것 같습니다. 더 명확하도록 게시물을 업데이트하겠습니다.
