So you’d like to automatically back up all your Discourse data every day?
Configuring daily backups
Go to the /admin settings, backup, and set backup_frequency to 1.
Now backup will be taken every day.
Store backups on the local server (default)
By default backups are stored on the local server disk.
If you’re self-hosted you can access them at /var/discourse/shared/standalone/backups/default.
Store backups on S3-compatible storage (using admin panel config)
You can also store backups on S3-compatible storage, such as AWS S3.
You can configure this either in the admin panel settings, or if you’re managing a self-hosted instance, also as environment variables in app.yml. For the latter, see further below.
In order to store backups on Amazon S3, you’ll need to create a unique, private S3 bucket and put it’s name in the s3_backup_bucket site setting.
You can follow most of the steps in Set up file and image uploads to S3 if you need help in setting up a new bucket.
WARNING
Storing backups and regular uploads in the same bucket and folder is no longer supported and will not work.
The
s3_backup_bucketpath should only be used for backups. If you need to use a bucket that contains other files please make sure that you provide a prefix when you configure thes3_backup_bucketsetting (example:my-awesome-bucket/backups) and make sure that files with that prefix are private.
Next, set your S3 credentials under the Files section: s3_access_key_id, s3_secret_access_key, and s3_region.
Finally, you need to select “S3” as backup_location.
From now on all backups will be uploaded to S3 and not be stored locally anymore. Local storage will only be used for temporary files during backups and restores.
Go to the Backups tab in the admin dashboard to browse the backups – you can download them any time to do a manual offsite backup.
Store backups on S3-compatible storage (using environment variables)
You can also configure S3 backups using environment variables in app.yml. For more information, see Configure an S3 compatible object storage provider for uploads
Note that the above article covers app.yml covers S3 setup for backups and for file/image uploads. If you only want to use S3 for backups (and not for uploads of files/images), then you can omit the following parameters from your app.yml config:
DISCOURSE_USE_S3DISCOURSE_S3_CDN_URLDISCOURSE_S3_BUCKET
You also don’t need to configure the after_assets_precompile step in this case, nor configure a CDN.
Be sure to include all other parameters that are required for your storage provider, as mentioned in the article. Here is one example configuration that only activates S3 for backups (for Scaleway S3):
DISCOURSE_S3_REGION: nl-ams
DISCOURSE_S3_ENDPOINT: https://s3.nl-ams.scw.cloud
DISCOURSE_S3_ACCESS_KEY_ID: my_access_key
DISCOURSE_S3_SECRET_ACCESS_KEY: my_secret_access_key
DISCOURSE_S3_BACKUP_BUCKET: my_bucket/my_folder
DISCOURSE_BACKUP_LOCATION: s3
Archiving to storage with a lower cost
Note that on AWS S3, you can also enable an automatic move to Glacier bucket lifecycle rule to keep your S3 backup costs low. Other storage providers often have a similar offering.