Não gosto do agendamento de backup mais frequente, que é apenas uma vez por dia. Isso parece que poderia descartar muito do trabalho cuidadoso de escrita de muitas pessoas em caso de desastre. No entanto, não quero configurar um cluster com HA; isso é pesado demais em termos de recursos para o meu caso de uso. Eu só quero ter um alto grau de confiança de que posso recuperar quase tudo o que foi escrito no meu Discourse, mesmo que isso leve um tempo. Este Discourse é um recurso gratuito para uma comunidade que não paga, então sou sensível ao valor que a comunidade atribui a ele, mas também sensível a custos adicionais. Tempo de inatividade é mais aceitável do que perda de dados.
Em um Discourse que ajudo a gerenciar, configurei imagens servidas localmente (mover imagens para o S3 é uma decisão irreversível, como descobri da maneira difícil) que usam minio-client para transmitir uploads para o S3 em tempo quase real, usando o recurso --watch. Estou fazendo isso a partir do host. (Isso não funciona com o Digital Ocean Spaces, embora; descobri da maneira difícil que limitações do Ceph causam essa falha.) Isso torna a recuperação simples, basta usar o minio-client para copiar todos os arquivos de volta. Um comando e tudo está de volta, até o instante exato, mesmo que o backup do banco de dados possa ter quase um dia de idade… Eu realmente gosto desse paradigma.
Parece-me que seria possível fazer o mesmo para streaming WAL archiving para o banco de dados sem usar um watch, mas em vez disso usando um archive_command que invoca o minio-client cada vez que um arquivo WAL é finalizado, apenas para aquele arquivo. No entanto, nesse caso, o minio teria que estar dentro do container com o postgres, não no host.
Isso me fez pensar…
Embora eu pudesse usar exec: nos meus arquivos yaml do container para adicionar o minio-client e fazer tudo isso por conta própria, o que vocês aqui achariam sobre o discourse/discourse_docker ter uma imagem/base/install-minio-client e um modelo padrão para colocar um .mc/config.json no lugar, adicionar um arquivo runit e permitir backup e recuperação de streaming bastante fáceis com base na configuração do container? Seria, obviamente, uma configuração avançada que vem com 
na documentação e não é ativada por padrão, mas como provavelmente farei o trabalho em algum lugar, em algum momento, se eu fizer isso no discourse/discourse_docker, será mais acessível do que se eu apenas modificar meu arquivo data.yml. O custo seria o minio-client na imagem base, que tem cerca de 21 MB; aproximadamente o dobro do tamanho do binário redis-server.
Não é uma promessa de fazer isso, apenas curioso se isso poderia ser aceito caso eu realmente faça o trabalho. 
Edição: Uma alternativa seria ter um diretório separado para copiar os arquivos e, em seguida, usar qualquer ferramenta como o minio-client fora do container para transmitir os dados para o local remoto, ou montar um sistema de arquivos remoto como o s3fs no local para o qual os arquivos são copiados. Isso pode ser uma configuração mais simples e flexível, com o mesmo resultado final e sem o peso de carregar o minio-client em todas as imagens do Discourse.