Мне не нравится наиболее частый график резервного копирования — всего один раз в день. Это кажется рискованным: в случае катастрофы можно потерять много тщательно написанного контента. Однако я не хочу развёртывать кластер с высокой доступностью (HA) — это слишком ресурсоёмко для моих задач. Мне просто нужна высокая уверенность в том, что я смогу восстановить почти всё, что было написано в моём Discourse, даже если на это потребуется время. Этот экземпляр Discourse — бесплатный ресурс для некоммерческого сообщества, поэтому я чувствителен к ценности, которую сообщество в него вкладывает, но также чувствителен к дополнительным затратам. Простой приемлемее, чем потеря данных.
На одном из Discourse, который я помогаю администрировать, я настроил локальное обслуживание изображений (перенос изображений в S3 — это «односторонняя дверь», как я убедился на собственном горьком опыте), используя minio-client для потоковой загрузки в S3 почти в реальном времени с помощью функции --watch. Я делаю это с хоста. (Это не работает с Digital Ocean Spaces; я на собственном опыте обнаружил, что ограничения Ceph приводят к сбою.) Это упрощает восстановление: достаточно использовать minio-client для копирования всех файлов обратно. Одна команда — и всё восстановлено вплоть до последнего момента, даже если резервная копия базы данных может быть почти дневной давности… Мне очень нравится этот подход.
Мне кажется, что можно сделать то же самое для потоковой архивации WAL для базы данных, не используя --watch, а вместо этого применяя archive_command, который запускает minio-client каждый раз, когда файл WAL завершается, обрабатывая только этот файл. Однако в этом случае minio должен находиться внутри контейнера вместе с PostgreSQL, а не на хосте.
Это заставило меня задуматься…
Хотя я мог бы использовать exec: в моих YAML-файлах контейнеров, чтобы добавить minio-client и сделать всё самостоятельно, что вы, коллеги, думаете о возможности включения в репозиторий discourse/discourse_docker образа/base/сценария install-minio-client и стандартного шаблона для размещения .mc/config.json, добавления файла runit и обеспечения относительно простого потокового резервного копирования и восстановления на основе конфигурации контейнера? Очевидно, это будет расширенная конфигурация, которая будет сопровождаться предупреждением 
в документации и не будет включена по умолчанию. Но поскольку я, вероятно, всё равно займусь этим в какой-то момент, если я сделаю это в рамках discourse/discourse_docker, это будет более доступно, чем если я просто изменю свой файл data.yml. Затраты заключаются в включении minio-client в базовый образ — это около 21 МБ, примерно вдвое больше размера бинарного файла redis-server.
Это не обещание сделать это, просто мне интересно, будет ли такой подход принят, если я действительно выполню работу. 
Редактирование: Альтернативный вариант — создать отдельную директорию для копирования файлов, а затем использовать любой инструмент, например minio-client, вне контейнера для потоковой передачи данных в удалённое хранилище или смонтировать удалённую файловую систему, такую как s3fs, в место, куда копируются файлы. Это может быть более простая и гибкая конфигурация с тем же конечным результатом, но без необходимости включать minio-client в каждый образ Discourse.