Configure automatic backups for Discourse

Documentation Self-Hosting
,
1

:bookmark: This guide explains how to configure automatic backups for Discourse, including storage options on local servers and S3-compatible storage.

Learn how to set up daily automatic backups for your Discourse platform.

This guide covers configuring daily backups, storing them on local servers or S3-compatible storage, and managing storage retention options like Amazon Glacier.

Configuring daily backups

  1. Navigate to /admin settings.
  2. Select the Backup section.
  3. Set the backup_frequency to 1.

backup_frequencybackup_frequency100%75%50%

Store backups on the local server

By default, backups are stored on your local server. For self-hosted instances, access them at /var/discourse/shared/standalone/backups/default.

Store backups on S3-compatible storage

Using the admin panel

  1. Create an S3 bucket.
  2. Set the s3_backup_bucket in the admin panel.
  1. Configure s3_access_key_id, s3_secret_access_key, and s3_region.
  2. Set backup_location to “S3”.

S3 configuration
S3 configuration854Ă—202 15.8 KB

image

:warning: WARNING

Storing backups and regular uploads in the same bucket and folder is no longer supported and will not work.

The s3_backup_bucket path 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 the s3_backup_bucket setting (example: my-awesome-bucket/backups) and make sure that files with that prefix are private.

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.

image
image807Ă—287 11.7 KB

Using environment variables in app.yml

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_S3
  • DISCOURSE_S3_CDN_URL
  • DISCOURSE_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.

Last edited by @SaraDev 2024-11-07T20:36:45Z

Check documentPerform check on document:
57 Likes
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.:

11 Likes
44

Setting this up can be rather confusing. Here’s a simple guide to help you out.

  • Log into your Discourse admin panel
  • Configure daily backups
  • Set maximum backups to 7
  • Log into your Amazon Web Services account
  • Go in the S3 Dashboard
  • Open the bucket containing the backups
  • Click on the properties tab
  • Activate versioning
  • Open the Lifecycle menu
  • Add a rule for the whole bucket
  • Set current version to expire after 15 days
  • Set previous version to
  • Archive to Glacier after 1 days
  • expire after 91 days
  • Save and logout

How it works

Versioning will keep backups automaticly deleted by Discourse. One day after beeing deleted it will be moved to the Glacier storage. After 91 days it will be delete from the Glacier storage.

Warning

Amazon charge you for item stored in Glacier for 90 days even if you delete them before. Make sure your Glacier Lyfecicle keep your file at least 90 days.

11 Likes
98

I may have missed this, but how to I make sure a bucket for backups is private the proper way? Setting up file and image uploads to S3 doesn’t seem to be described here.

1 Like
99

Looks like there is no such option anymore.

UPD: ah, now it’s split into 2 steps of this wizard.

So I guess it should be like this:

image
image646Ă—595 78.2 KB

image
image636Ă—550 49.2 KB

image
image682Ă—504 31 KB

2 Likes
100

Does S3 backup functionality play nice without IAM access key and secret if using AWS roles assigned to the instance and s3 use iam profile is enabled in the settings menu?

Edit: The answer is YES! Just ensure you have region set appropriately.

1 Like
101

I had this problem too, which was resolved by adding a couple of lines to the policy document:

"Resource": [
        "arn:aws:s3:::your-uploads-bucket",
        "arn:aws:s3:::your-uploads-bucket/*",
        "arn:aws:s3:::your-backups-bucket",
        "arn:aws:s3:::your-backups-bucket/*"
      ]

Should this be added to the OP (which isn’t a wiki)? Or perhaps in the OP of Set up file and image uploads to S3?

2 Likes
102

Is there a good reason not to make daily backups aren’t the default?

Fixes needed for OP

Add something about moving S3 backups to Glacier?
Delete the S3 stuff and link to Configure an S3 compatible object storage provider for uploads

103

It’d be overkill and expensive. Same reason we don’t recommend changing the oil in your car every 500 miles?

104

You back up your servers once a week?

I think your 500 mile oil change analogy would be a good answer for “why not keep 30 backups?”, but it doesn’t make sense to me here.

Do you not think that if you’re going to have 5 backups most people would rather have backups every day so that if they do have to revert to a backup they’ve lost no more than a day? The only time I remember an older backup being useful is when images fell out of tombstone.

If they have so little disk space that they can’t hold 5 backups, it would seem better to learn that in 5 days when they still have some memory of what they did than wait 4-5 weeks.

1 Like
105

Yes, that is correct, for my self hosted servers.

If you prefer different settings, feel free to edit them from the defaults. What’s stopping you from doing so?

1 Like
106

Well, I’ll be!

I’m cleaning up topics like this one. If the defaults were changed, it wouldn’t be needed!

I’m convinced that the defaults won’t be changed, so I’ll move ahead. :wink

2 Likes
107

Once a week is a good starting point and a solid default.

1 Like
108

I had the very same problem!

i suggest to add a note regarding this on the initial post too!

3 Likes
109

Would be nice if this could be used to upload to a different S3 compatible provider, such as running MinIO.

110

If you want to use minio, see Using Object Storage for Uploads (S3 & Clones). If you want different services for backups and assets then you’re out of luck (though there are ways to set up triggers to copy from one bucket 8 another)

111

No, just want for backups, so they get automatically pushed to a different machine on my network.

112

Then the guide I linked is what you’re looking for.

1 Like
113

Is it possible to be more frequent than once per day? I’d rather not make assumptions and set backup freqeuncy to a float

1 Like
114

If you want more frequent backups you’ll need to do them externally.

3 Likes