If you are self-hosted, you should keep off-site backups in case there is some catastrophic problem with your server. Imagine that went out of business one day without any warning, or you somehow managed to delete
/var/discourse, wiping away your entire installation.
The Bare Minimum
See that backups are enabled.
Site Settings to consider:
enable backups: on (default on)
backup frequency: How much data are you willing to to lose? (Default: 7 days). @pfaffman recommends one day
backup time of day: When do you want your forum to be read-only while it takes a backup?
backup with uploads: On unless you have uploads stored elsewhere or back them up some other way. (Default: on)
maxiumum backups: How paranoid are you? How much disk space do you have? (Default: 5)
This will allow you to restore to a recent backup should your database somehow become corrupted, but will not protect you if your Discourse server goes away.
To restore your site on a new server, at a minimum, you need the backup that Discourse creates. It’ll be much easier to set up a new server if you have the container(s) in
Exactly how to keep off-site backups is somewhat beyond the scope of this document, but one method is to use a tool like
rsync to copy the data to a remote server. There are dozens of guides for doing that; find one that makes sense to you.
/var/discourse/containers file(s) change infrequently, so backing them up by hand only when you make changes isn’t that painful. They typically contain your SMTP and plugins, which are reasonably easy to rebuild from memory, but you’d rather not be doing that in an emergency. If that were to happen you could still get things going again missing a few plugins with mail broken and figure out the rest with the site limping along.
Backing up to S3
The most convenient way to keep off-site backups is to push them to S3 as described at Setting up file and image uploads to S3. If you do that and keep your S3 config settings somewhere you can find them (or in your app
.yml), you can restore your site directly from S3 when you have the new server set up.
It’s possible to embed settings in your
app.yml file. If you include something like this in the
env section of your
app.yml, these settings will disappear from the web interface you’ll be able to Restore a backup from command line without having to create an admin account and log in.
DISCOURSE_S3_ACCESS_KEY_ID: 'key' DISCOURSE_S3_SECRET_ACCESS_KEY: 'secret' DISCOURSE_BACKUP_LOCATION: 's3' DISCOURSE_ENABLE_S3_UPLOADS: true DISCOURSE_S3_BACKUP_BUCKET: 'my-backup-bucket' DISCOURSE_S3_REGION: 'us-west-1'
If you also have uploads in S3 and your trust your S3 provider to be stable, you could have Discourse backing up only the database (see setting above). This will keep you from storing multiple copies of all of your uploads. If you opt for this route, you should do a test restore to make sure that indeed all of your uploads are in S3.
Practice Makes Perfect
While having a copy of only your most recent backup is the bare minimum you’ll need to restore in a crisis, if you want to be really sure that your backups work, you should test them at least once, if not periodically. Spin up a new server and see if you can restore from a backup.