Configure automatic backups for Discourse


(Jeff Atwood) #1

So you’d like to automatically back up all your Discourse data every day?

Go to the /admin settings, backup, and set backup frequency to 1.

Now backup will be taken every day.

Backups are always saved on the local server disk by default.

If you want to also automatically upload your backups to Amazon S3, check enable s3 backups. You’ll need to create a unique private S3 bucket name in s3 backup bucket to store your backups.

Next, set your S3 credentials under the Files section: s3 access key id, s3 secret access key, and s3 region.

Backups are always stored on local server disk. Go to the Backups tab in the admin dashboard to browse your local server backups – you can download them any time to do a manual offsite backup.

If you’ve enabled S3 backups, check your S3 bucket to find the uploaded backup files:

Note that you can also enable an automatic move to Glacier bucket lifecycle rule to keep your S3 backup costs low.


How to make a private bucket on Amazon S3 for backup?
Backups not uploading to S3
Enable a CDN for your Discourse
Public data dumps
Backups not uploading to S3
Install Discourse on Amazon WS with Cloudflare
How to make a private bucket on Amazon S3 for backup?
Setting up SSL with my domain name and Discourse instance
Backup to S3 configuration problem
Download backup - email link only
Launcher rebuild fails if s3 settings aren't correct
Awareness for path dependencies when setting up a discourse forum
Proper Procedure for Upgrading Discourse Docker Container
(Mittineague) #2

Looks good!

Is the “when” an option? i.e. low traffic time. Or does the back-up process not affect site performance?


(Kevin P. Fleming) #3

Just a future thought: if the Discourse instance in question is running on AWS, it’s better to not hardcode the access credentials and just the AWS IAM role features to give S3 permissions to the machine that the Discourse instance lives on. The AWS API libraries will then use these implicit credentials automatically.

See the documentation here Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances - AWS Identity and Access Management.


(Justin Gordon) #4

What about the Enable Backups option when creating the Droplet?


(Jeff Atwood) #5

You can, but they won’t be offsite. Not sure how DO backup scheme works.


(Dave McClure) #10

Does the user need to have the custom policy edited along the same lines as documented here?


(Régis Hanol) #11

Yes s/he does! At the very least s/he needs to be able to add/remove files in the backup bucket.


(Tobias Eigen) #14

I actually recommend NOT using the DO automated backups. It is better to create one-off snapshots from time to time via the DO control panel, and especially before doing anything that changes the server paths or docker settings.

I learned the hard way that the DO backups can and likely do have corrupted databases because discourse is not paused during the backup. When you do a snapshot manually you can control this.

Meanwhile if you run into difficulties later and have discourse created offsite backups they are clean and work like a charm to recover.


(Arthur Ulfeldt) #15

Lots of info here about creating backup tarballs,
How do I go about using one of them to restore the server?


(Jeff Atwood) #16

Go to Admin, Backups then use the Upload button.

Once you’ve done that press the “Restore” button next to the backup.

Note that you’ll need to enable restore in the site settings as a safety measure. The tooltip on the disabled restore button indicates this.


(Oliver Mark) #23

You are able to Archive Backups from your S3 Bucket to Glacier.
It is cheaper, but an Restore attemps more Time.

This Site will Help you to reduce Backup costs.:


(Tenzan) #28

You forgot to mention that backup feature in DO is not free and it has to be enabled at the time you’re creating a droplet.


(Sam) #31

Re this:

Is this something that can be altered? I looked around and didn’t find an answer anywhere. The performance hit isn’t all that bad, but I’d just as soon move the backup to a more inactive time on the site. Post-DST it runs at about 10PM EST, which is not ideal.


(Tobias Eigen) #32

I always do DO backups manually after a clean shutdown. Otherwise the Discourse automated backups are plenty.


(Sam) #33

Don’t mean to be a nuisance, but is this something I can configure?

I’m not sure if you were intending to answer my question @tobiaseigen, to clarify I want to know if there’s somewhere I can change the schedule for Discourse’s automated backups so that they don’t occur during my community’s prime time.

Apologies if this is something that’s really obvious how to do for the more experienced folks, if so it’s just a gap in my knowledge that I definitely would like to fill in.


(Jeff Atwood) #34

Setting time of day for backup in site settings would be a nice feature @zogstrip.


(Chris Saenz) #35

The ability to schedule a database-only backup would be really nice too…


(Régis Hanol) #36

That is now done :fries:

https://github.com/discourse/discourse/commit/72a7bd38e1070a2ee92832d6284d1beceb12307a


Contributing.md mentions a CHANGELOG
(Régis Hanol) #37

There you go :hamburger:


(Sam) #38

@zogstrip ~ could you provide some guidance on how the backup_time_of_day setting works? Leaving it at the default of 3:30 seems to keep backups running at a little after 10:00 PM EST, which is a bit difficult to interpret.

Just a quick clarification of setting to time zone or some such would work. I’ll figure it out through trial and error if necessary, but a little explanatory text might be helpful for the setting.

Actually - is this correct: the ScheduleBackup job runs at about 7PM EST for me, so the time_of_day setting is just offset from this, so +3.5hrs goes to 10:30PMish? Just noticed that, thought it would be a weird coincidence if that’s not the case, but still could be I suppose.