Ich mag den häufigsten Backup-Plan von nur einmal pro Tag nicht. Das scheint potenziell viel sorgfältiges Schreiben vieler Leute zu sein, das im Katastrophenfall verloren gehen könnte. Allerdings möchte ich kein Cluster mit HA einrichten; das ist für meinen Anwendungsfall zu ressourcenintensiv. Ich möchte lediglich ein hohes Maß an Sicherheit haben, dass ich fast alles, was auf meinem Discourse geschrieben wurde, wiederherstellen kann, auch wenn es etwas länger dauert. Dieses Discourse ist eine kostenlose Ressource für eine nicht zahlende Community, daher bin ich sensibel für den Wert, den die Community hineinsteckt, aber auch sensibel gegenüber zusätzlichen Kosten. Ausfallzeiten sind akzeptabler als Datenverlust.
Bei einem Discourse, das ich mitverwalte, habe ich lokal bereitgestellte Bilder eingerichtet (das Verschieben von Bildern zu S3 ist eine Einbahnstraße, wie ich auf die harte Tour erfahren habe), die minio-client verwenden, um Uploads in Echtzeitnahe Nähe zu S3 zu streamen, und zwar mit der --watch-Funktion. Ich führe dies vom Host aus durch. (Das funktioniert jedoch nicht mit Digital Ocean Spaces; ich habe auf die harte Tour erfahren, dass Ceph-Einschränkungen dazu führen, dass dies fehlschlägt.) Dies macht die Wiederherstellung einfach: Man verwendet einfach minio-client, um alle Dateien zurückzukopieren. Ein Befehl, und alles ist wiederhergestellt, bis zur letzten Sekunde, obwohl das Datenbank-Backup fast einen Tag alt sein könnte … Ich mag dieses Paradigma wirklich.
Es scheint mir, dass es möglich wäre, dasselbe für streaming WAL-Archivierung für die Datenbank zu tun, ohne eine Watch zu verwenden, sondern stattdessen einen archive_command, der minio-client jedes Mal aufruft, wenn eine WAL-Datei auf dieser einen Datei finalisiert wird. In diesem Fall müsste Minio jedoch im Container mit PostgreSQL leben, nicht auf dem Host.
Das hat mich zum Nachdenken gebracht…
Obwohl ich exec: in meinen Container-YAML-Dateien verwenden könnte, um minio-client hinzuzufügen und dies alles selbst zu erledigen, was würden die Leute hier dazu denken, wenn discourse/discourse_docker image/base/install-minio-client und eine Standardvorlage hätte, um eine .mc/config.json zu platzieren, eine runit-Datei hinzuzufügen und eine recht einfache Streaming-Backup- und Wiederherstellung basierend auf der Containerkonfiguration zu ermöglichen? Es wäre offensichtlich eine erweiterte Konfiguration, die in der Dokumentation mit 
gekennzeichnet ist und standardmäßig nicht aktiviert ist. Da ich die Arbeit wahrscheinlich irgendwann irgendwo erledigen werde, wäre es zugänglicher, wenn ich es in discourse/discourse_docker mache, als wenn ich einfach meine data.yml-Datei hacke. Die Kosten wären minio-client im Basis-Image, was etwa 21 MB beträgt; etwa doppelt so groß wie die redis-server-Binary.
Keine Zusage, dies zu tun, nur neugierig, ob es angenommen werden könnte, falls ich die Arbeit tatsächlich erledige. 
Edit: Eine Alternative wäre, ein separates Verzeichnis zum Kopieren der Dateien zu haben und dann ein beliebiges Tool wie minio-client außerhalb des Containers zu verwenden, um die Daten an den Remote-Standort zu streamen, oder ein Remote-Dateisystem wie s3fs auf dem Standort zu mounten, an den die Dateien kopiert werden. Das könnte eine einfachere, flexiblere Konfiguration mit demselben Endergebnis sein, ohne das Gewicht von minio-client in jedem Discourse-Image mitzuführen.