Non mi piace la configurazione di backup più frequente, che avviene solo una volta al giorno. Sembra che in caso di disastro si rischi di perdere molto del lavoro meticoloso di molte persone. Tuttavia, non voglio configurare un cluster con HA; è troppo pesante in termini di risorse per il mio caso d’uso. Voglio semplicemente avere un alto grado di fiducia nel poter recuperare quasi tutto ciò che è stato scritto sul mio Discourse, anche se ci vuole un po’ di tempo. Questo Discourse è una risorsa gratuita per una comunità non pagante, quindi sono sensibile al valore che la comunità ci attribuisce, ma anche ai costi aggiuntivi. I tempi di inattività sono più accettabili della perdita di dati.
Su un Discourse che aiuto a gestire, ho configurato immagini servite localmente (spostare le immagini su S3 è una strada a senso unico, come ho scoperto a mie spese) che utilizzano minio-client per trasmettere gli upload su S3 in tempo quasi reale, sfruttando la funzionalità --watch. Lo sto facendo dall’host. (Questo non funziona con Digital Ocean Spaces, però; ho scoperto a mie spese che le limitazioni di Ceph causano il fallimento di questa operazione.) Questo rende il ripristino semplice: basta usare minio-client per copiare tutti i file indietro. Un solo comando e tutto è di nuovo disponibile, fino all’ultimo istante, anche se il backup del database potrebbe essere vecchio di quasi un giorno… Mi piace davvero questo paradigma.
Mi sembra che sarebbe possibile fare la stessa cosa per l’archiviazione in streaming dei WAL per il database senza utilizzare watch, ma invece impiegando un archive_command che invoca minio-client ogni volta che un file WAL viene completato, agendo solo su quel file. In tal caso, però, minio dovrebbe risiedere nel contenitore insieme a postgres, non sull’host.
Questo mi ha fatto riflettere…
Potrei usare exec: nei miei file yaml del contenitore per aggiungere minio-client e fare tutto da solo, ma cosa ne penserebbero gli utenti qui riguardo all’aggiunta di image/base/install-minio-client in discourse/discourse_docker e di un modello standard per inserire un .mc/config.json, aggiungere un file runit e abilitare un backup e un ripristino in streaming abbastanza semplici basati sulla configurazione del contenitore? Sarebbe ovviamente una configurazione avanzata, accompagnata da 
nella documentazione e non attivata di default, ma dato che probabilmente lo farò prima o poi, se lo facessi in discourse/discourse_docker sarebbe più accessibile rispetto a modificare manualmente il mio file data.yml. Il costo sarebbe l’inclusione di minio-client nell’immagine base, circa 21 MB; circa il doppio della dimensione del binario redis-server.
Non è una promessa di farlo, sono solo curioso di sapere se potrebbe essere accettato nel caso in cui effettivamente svolga il lavoro. 
Modifica: Un’alternativa sarebbe avere una directory separata dove copiare i file e poi utilizzare qualsiasi strumento come minio-client al di fuori del contenitore per trasmettere i dati alla posizione remota, oppure montare un filesystem remoto come s3fs nella posizione in cui i file vengono copiati. Potrebbe essere una configurazione più semplice e flessibile, con lo stesso risultato finale, e senza il peso di includere minio-client in ogni immagine di Discourse.