하루에 단 한 번만 이루어지는 가장 흔한 백업 주기는 마음에 들지 않습니다. 재해가 발생했을 경우, 많은 사용자의 정성스러운 글쓰기가 사라질 수 있다는 점이 우려됩니다. 하지만 HA(고가용성) 클러스터를 구축하는 것은 제 사용 사례에 비해 리소스 소모가 너무 큽니다. 저는 디스코urse에 기록된 거의 모든 데이터를 복원할 수 있다는 높은 확률을 원할 뿐, 시간이 좀 걸리더라도 괜찮습니다. 이 디스코urse는 비유료 커뮤니티를 위한 무료 리소스이므로, 커뮤니티가 투입하는 가치에 민감하면서도 추가 비용에도 민감합니다. 다운타임은 데이터 손실보다 더 허용 가능합니다.
제가 관리에 도움을 주는 디스코urse 중 하나에서는 로컬에서 서빙되는 이미지(이미지를 S3로 옮기는 것은 되돌릴 수 없는 일방통행이라는 것을 어렵게 깨달았습니다)를 사용하고 있으며, --watch 기능을 사용하여 minio-client로 업로드를 S3에 준실시간으로 스트리밍합니다. 이는 호스트 레벨에서 수행하고 있습니다. (다만 Digital Ocean Spaces에서는 작동하지 않습니다. Ceph의 제한 사항으로 인해 실패한다는 것을 어렵게 발견했습니다.) 이렇게 하면 복구가 간단해집니다. minio-client를 사용하여 모든 파일을 복사해 오기만 하면 되므로, 데이터베이스 백업이 하루 가까이 오래되었더라도 마지막 순간까지의 데이터를 복원할 수 있는 단일 명령어면 충분합니다. 저는 이 패러다임을 정말 좋아합니다.
저의 생각으로는, 워치(watch) 대신 wal 파일이 완료될 때마다 해당 파일에 대해 minio-client를 호출하는 archive_command를 사용하여 데이터베이스에 대해 스트리밍 WAL 아카이빙을 수행하는 것이 가능할 것 같습니다. 하지만 그 경우, minio는 호스트가 아니라 postgres와 같은 컨테이너 내에 존재해야 합니다.
이로 인해 이런 생각이 들었습니다…
컨테이너 yaml 파일에 exec:를 사용하여 minio-client를 추가하고 이 모든 작업을 제 스스로 수행할 수는 있지만, 여기서의 분들은 discourse/discourse_docker에 image/base/install-minio-client를 포함하고, .mc/config.json을 배치하는 표준 템플릿, runit 파일 추가, 그리고 컨테이너 구성을 기반으로 비교적 쉬운 스트리밍 백업 및 복구를 가능하게 하는 것에 대해 어떻게 생각하시나요? 이는 문서에 
표시가 붙고 기본적으로 활성화되지 않는 고급 구성이 될 것입니다. 하지만 언젠가 제 스스로 이 작업을 수행하게 될 가능성이 높으므로, discourse/discourse_docker에서 수행하면 제 data.yml 파일을 단순하게 해킹하는 것보다 접근성이 더 좋습니다. 비용은 베이스 이미지 내의 minio-client가 될 것이며, 이는 약 21MB로 redis-server 바이너리 크기의 약 2배입니다.
이를 반드시 하겠다는 약속은 아니며, 실제로 작업을 수행하게 된다면 받아들여질 수 있을지 궁금할 뿐입니다. 
수정: 대안으로, 파일을 복사할 별도의 디렉토리를 두고, 컨테이너 외부에서 minio-client와 같은 도구를 사용하여 데이터를 원격 위치로 스트리밍하거나, 파일이 복사되는 위치에 s3fs와 같은 원격 파일시스템을 마운트하는 방식이 있습니다. 이는 동일한 최종 결과를 내면서 minio-client를 모든 discourse 이미지에 포함시키는 부담 없이, 더 단순하고 유연한 구성이 될 수 있습니다.