In a discussion about extending Discourse’s automated backup feature beyond Amazon S3, users explore options like SFTP, SCP, Docker Hub, and third-party services. Jonathan_Wexler initiates the thread, expressing that non-S3 backup setups are overly complex, requiring manual scripting and third-party API access. riking clarifies that backups default to /var/discourse/shared/standalone/backups/default, and codinghorror notes users can script uploads to any destination. Jonathan_Wexler proposes a UI dropdown to select cloud storage providers, citing the Tagger plugin’s integration as a cautionary example. He argues such core features should be spec’d on Discourse, not GitHub, and suggests visual workflow mapping (e.g., LucidChart) to simplify development. codinghorror encourages PRs for new backup methods, clarifying “pull request” means contributors write and submit code for review. zogstrip explains PRs involve requesting repo owners to “pull” contributed code. Mittineague and Jonathan_Wexler humorously critique GitHub’s naming conventions. codinghorror affirms multi-destination backups are valuable but currently low-priority due to bandwidth constraints. A related thread on Dropbox backups is linked by Falco. The conversation blends technical detail, feature advocacy, and community process, highlighting user desire for simpler, built-in multi-cloud backup support.
Continuing the discussion from Hot off the presses, automated backup support!:
I also will not use S3 - what is that - AWS? I would like to use Dropbox or even some other backup solution as I find AWS totally convoluted.
How can I create a process where backups are sent to other destinations?
I will have to experiment, but this was my initial concern.
You can make automatic local (on your server) backups and download them from your web browser to whatever destination you like.
Okay that answers my question - thanks.
For SFTP/SCP, they’ll be dropped in /var/discourse/shared/standalone/backups/default.
I still think it is too complicated to use non-Amazon storage. Someone should make a better solution for this. I have to automate the drops on the server and then script it to other services - is something like that correct?
So the steps are:
Why not just include an option to send to other storage services on this page?
Not quite what Discourse actually sees, but close enough.
Nope, you can skip #2. Just run a cronjob to grab the latest one.
Ya seems simple to do actually.
Also, because Discourse is in a Docker container, can I just automate a container upload to Docker Hub periodically?
And a download sync of the Discource Docker container would be useful - this has me thinking of a much better solution that Amazon S3.
In order to do that, you need to:
./launcher bootstrap app on a build serverdocker save) THAT container, which is specific to YOUR sitedocker load that container on the destinationIt’s a lot of work for mostly no gain, except when you’re on a scale similar to the discourse.org hosting.
PRs are welcome in this area. If someone wants to build a FTP backup transfer plugin, or a Dropbox one, or Google Drive, that’d be fine.
There should be a drop-drop to select which cloud storage to backup to automatically.
See screenshot below:
I followed how the Tagger plugin incorporation did not happen right, so when @codinghorror simply states to add it as a pull request it seems like he is pushing it aside, when, for example, the Tagger plugin was also really import and is still quite cumbersome to get working.
Something like automatic backups should be given a much higher priority.
I also feel features should be speced right here in this Discourse forum, not in GitHub, which, after all, is a separate website in reality.
If we map out the process, say in LucidChart, and just post a screenshot of it here, I think any software architect would understand how to build it.
@sam I have been a technical writer for many years, and the first thing to get clear is the language of the project, which is a lesson I learnt especially here in Montreal as we work in French and English and produce a lot of software.
It is very simplistic to think everyone wants to rely on Amazon storage when there are a lot of other very good providers, both US based, and worldwide.
Something like this:
And also an easy option to backup the whole Docker container to Docker Up should be done:
He means a Pull Request, which in turn mean is somebody cares to write the computer code to make it happen then we are fine with that.
I submitted it to GitHub.
Sorry, misunderstanding, pull request means you do the work to build the feature by writing the code to implement it. Or paying someone else to.
Why is it called pull request then? What is being pulled?
You mean you pull the code from Github, do the work, then submit it for community approval?
Peut-être on doit changer la terminologie un peut car les mots technique sont très mal construit pour les processus très technique.
It’s a github thing
IMHO if I am submitting something “push” does seem more appropriate.
Why is it vagrant up but not vagrant down?
Or if vagrant halt why not vagrant start?
Why do arrays start at “0” instead of “1”?
Ah, the logic of techies is more than enough to confound 
Yes I completely agree. They should have read 0 : The Biography of a Dangerous Idea.
Here’s a pic, and let’s see if anyone can explain this with technical language:
I recommend that you read the tutorial about how to use pull requests.
The TL;DR is that you write some code and then ask the owners of the repository to pull your code in.
“Pull request” est un terme connu par tous les développeurs qui utilisent GitHub
“Pull request” is a well known term by all the developers who uses GitHub
To be clear, I think multiple backup destinations is a good idea, we just have no bandwidth to work on it at the moment and none of our paying customers are specifically asking for it.
