Best Practices for Backups

documentation sysadmin
1

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.

Remote Backups

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 /var/discourse//containers.

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.

Your /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 Set 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 the 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.

25 Likes