Je n’aime pas le programme de sauvegarde le plus fréquent, qui n’est qu’une fois par jour. Cela semble potentiellement risquer de perdre beaucoup de travaux soigneusement rédigés par les utilisateurs en cas de catastrophe. Cependant, je ne veux pas mettre en place un cluster avec haute disponibilité (HA) ; c’est trop gourmand en ressources pour mon cas d’usage. Je souhaite simplement avoir un haut degré de confiance dans ma capacité à récupérer presque tout ce qui a été écrit sur mon Discourse, même si cela prend un certain temps. Ce Discourse est une ressource gratuite pour une communauté non payante, je suis donc sensible à la valeur que la communauté y investit, mais aussi aux coûts supplémentaires. Les temps d’arrêt sont plus acceptables que la perte de données.
Sur un Discourse que j’aide à gérer, j’ai configuré des images servies localement (le déplacement des images vers S3 est une porte à sens unique, comme je l’ai appris à la dure) qui utilisent minio-client pour transmettre les uploads vers S3 en temps quasi réel, en utilisant la fonctionnalité --watch. Je le fais depuis l’hôte. (Cela ne fonctionne pas avec Digital Ocean Spaces cependant ; j’ai appris à la dure que les limitations de Ceph provoquent cet échec.) Cela rend la récupération simple, il suffit d’utiliser minio-client pour copier tous les fichiers. Une seule commande et tout est de nouveau là, jusqu’à l’instant précis, même si la sauvegarde de la base de données peut dater d’environ un jour… J’aime vraiment ce paradigme.
Il me semble qu’il serait possible de faire la même chose pour l’archivage en continu des WAL de la base de données sans utiliser watch, mais en utilisant plutôt une archive_command qui invoque minio-client à chaque fois qu’un fichier WAL est finalisé, uniquement pour ce fichier. Cependant, dans ce cas, minio devrait résider dans le conteneur avec PostgreSQL, et non sur l’hôte.
Cela m’a fait réfléchir…
Bien que je puisse utiliser exec: dans mes fichiers YAML de conteneur pour ajouter minio-client et faire tout cela moi-même, qu’en pensez-vous ici concernant l’ajout de image/base/install-minio-client dans discourse/discourse_docker et d’un modèle standard pour placer un fichier .mc/config.json, ajouter un fichier runit, et permettre une sauvegarde et une récupération par flux assez faciles basées sur la configuration du conteneur ? Ce serait évidemment une configuration avancée accompagnée d’un 
dans la documentation et qui n’est pas activée par défaut, mais puisque je ferai probablement ce travail à un moment ou à un autre, si je le fais dans discourse/discourse_docker, cela sera plus accessible que si je modifie simplement mon fichier data.yml. Le coût serait l’ajout de minio-client dans l’image de base, soit environ 21 Mo ; environ deux fois la taille du binaire redis-server.
Pas une promesse de le faire, juste curieux de savoir si cela pourrait être accepté au cas où je ferais réellement le travail. 
Édition : Une alternative consisterait à avoir un répertoire séparé pour copier les fichiers, puis d’utiliser n’importe quel outil comme minio-client en dehors du conteneur pour transmettre les données vers l’emplacement distant, ou de monter un système de fichiers distant comme s3fs sur l’emplacement vers lequel les fichiers sont copiés. Cela pourrait être une configuration plus simple et plus flexible, avec le même résultat final, et sans le poids d’embarquer minio-client dans chaque image Discourse.