No me gusta que el programa de copias de seguridad más frecuente sea solo una vez al día. Eso parece como si mucha gente pudiera perder un trabajo escrito con mucho cuidado en caso de desastre. Sin embargo, no quiero configurar un clúster con HA; eso consume demasiados recursos para mi caso de uso. Solo quiero tener un alto grado de confianza de que puedo recuperar casi todo lo escrito en mi Discourse, aunque pueda llevar un tiempo. Este Discourse es un recurso gratuito para una comunidad que no paga, por lo que soy sensible al valor que la comunidad le otorga, pero también a los costos adicionales. El tiempo de inactividad es más aceptable que la pérdida de datos.
En un Discourse que ayudo a gestionar, he configurado imágenes servidas localmente (mover imágenes a S3 es una puerta de un solo sentido, como descubrí de la manera difícil) que utilizan minio-client para transmitir las subidas a S3 en tiempo casi real, usando la funcionalidad --watch. Lo estoy haciendo desde el host. (Esto no funciona con Digital Ocean Spaces, aunque; descubrí de la manera difícil que las limitaciones de Ceph causan que esto falle.) Esto hace que la recuperación sea sencilla, simplemente usando minio-client para copiar todos los archivos de vuelta. Un comando y todo está de vuelta, hasta el instante, aunque la copia de seguridad de la base de datos pueda tener casi un día de antigüedad… Me encanta este paradigma.
Parece que sería posible hacer lo mismo para la archivación continua de WAL para la base de datos sin usar un watch, sino usando un archive_command que invoque a minio-client cada vez que se finalice un archivo wal, solo para ese archivo. Sin embargo, en ese caso, minio tendría que vivir dentro del contenedor con postgres, no en el host.
Eso me hizo pensar…
Aunque podría usar exec: en mis archivos yaml del contenedor para agregar minio-client y hacer todo yo mismo, ¿qué opinaría la gente aquí sobre que discourse/discourse_docker tenga image/base/install-minio-client y una plantilla estándar para colocar un .mc/config.json, agregar un archivo runit y permitir una copia de seguridad y recuperación en streaming bastante fácil basada en la configuración del contenedor? Obviamente, sería una configuración avanzada que vendría con 
en la documentación y no estaría activada por defecto, pero como probablemente haré el trabajo en algún momento, si lo hago en discourse/discourse_docker será más accesible que si simplemente modifico mi archivo data.yml. El costo sería minio-client en la imagen base, que tiene unos 21 MB; aproximadamente el doble del tamaño del binario redis-server.
No es una promesa de hacerlo, solo tengo curiosidad por saber si podría ser aceptado si realmente hago el trabajo. 
Edición: Una alternativa sería tener un directorio separado donde copiar los archivos y luego usar cualquier herramienta como minio-client fuera del contenedor para transmitir los datos a la ubicación remota, o montar un sistema de archivos remoto como s3fs en la ubicación a la que se copian los archivos. Eso podría ser una configuración más simple y flexible, con el mismo resultado final, y sin el peso de llevar minio-client en cada imagen de Discourse.