Configure automatic backups for Discourse

: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 automatic backups for your Discourse platform.

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

Configuring automatic backups

  1. Navigate to /admin settings.
  2. Select the Backup section.
  3. Set backup_frequency to the desired interval in days. The default is 7 (weekly). Set to 1 for daily backups, or 0 to disable automatic backups. The maximum is 30.

backup_frequencybackup_frequency100%75%50%

Additional backup settings

  • backup_time_of_day — the time of day (UTC) when backups run. Default: 3:30.
  • backup_with_uploads — include uploads in scheduled backups. Default: enabled. Disabling this will only back up the database.
  • maximum_backups — the maximum number of backups to keep. Older backups are automatically deleted. Default: 5.
  • remove_older_backups — remove backups older than the specified number of days. Leave blank to disable.

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”.

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.

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:
60개의 좋아요

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개의 좋아요

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개의 좋아요

놓쳤을 수도 있지만, 백업용 버킷을 제대로 비공개로 설정하는 방법은 무엇인가요? Set up file and image uploads to S3 이 내용은 여기에 설명되어 있지 않은 것 같습니다.

1개의 좋아요

이 옵션이 더 이상 없는 것 같습니다.

UPD: 아, 이제 이 마법사의 2단계로 나뉘어 있네요.

그러면 이렇게 되어야 할 것 같습니다:

2개의 좋아요

인스턴스에 AWS 역할을 할당하고 settings 메뉴에서 s3 use iam profile이 활성화된 경우, IAM 액세스 키와 시크릿 없이 S3 백업 기능이 정상적으로 작동합니까?

수정: 답은 네! 지역(region)을 적절히 설정했는지 확인하세요.

1개의 좋아요

저도 같은 문제를 겪었었는데, 정책 문서에 몇 줄을 추가하여 해결했습니다:

"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/*"
      ]

이 내용을 원글(OP, 위키가 아닌 경우)에 추가해야 할까요? 아니면 Set up file and image uploads to S3 의 원글에 추가하는 것이 좋을까요?

2개의 좋아요

일일 백업을 기본값으로 설정하지 않는 데에는 좋은 이유가 있을까요?

OP에 필요한 수정 사항

S3 백업을 Glacier로 이동하는 것에 대한 내용을 추가할까요?
S3 관련 내용을 삭제하고 Configure an S3 compatible object storage provider for uploads 링크를 추가할까요?

그건 과하고 비용이 많이 듭니다. 차의 엔진 오일을 500마일마다 교체할 것을 권장하지 않는 것과 같은 이유입니다.

서버를 일주일에 한 번만 백업하시나요?

500마일(약 800km)마다 오일 교환을 해야 한다는 비유는 "왜 30개의 백업을 유지하지 않나요?"라는 질문에 좋은 답변이 될 수 있다고 생각합니다. 하지만 이 상황에서는 제게는 이해가 안 됩니다.

5개의 백업을 유지한다면, 대부분의 사람들이 백업으로 복원해야 할 때 하루치 이상의 데이터를 잃지 않도록 매일 백업하는 것을 더 선호하지 않을까요? 제가 기억하는 한, 오래된 백업이 유용했던 경우는 이미지들이 tombstone에서 사라졌을 때뿐이었습니다.

디스크 공간이 부족해서 5개의 백업을 유지할 수조차 없다면, 5일 후 아직 무엇을 했는지 기억이 남아 있을 때 그 사실을 알아차리는 것이 4~5주를 기다리는 것보다 나을 것 같습니다.

1개의 좋아요

네, 맞습니다. 제 셀프호스팅 서버의 경우 그렇게 하고 있습니다.

다른 설정을 원하시면 기본값을 수정해 주셔도 됩니다. 그렇게 하지 못하게 막는 것이 있나요?

1개의 좋아요

와, 정말 놀랍네요!

이런 주제들을 정리하고 있습니다. 기본값이 변경되었다면 이런 작업이 필요하지 않을 텐데요!

기본값은 변경되지 않을 것이라고 확신하므로, 앞으로 진행하겠습니다. :wink

2개의 좋아요

주 1회는 좋은 시작점이자 안정적인 기본값입니다.

1개의 좋아요

저도 정확히 같은 문제가 있었습니다!

초기 게시물에도 이 내용에 대한 주의를 추가하는 것을 제안합니다!

3개의 좋아요

이 기능이 MinIO와 같은 다른 S3 호환 프로바이더에 업로드하는 데에도 사용될 수 있으면 좋겠습니다.

minio를 사용하려면 업로드용 객체 스토리지 사용 (S3 & 클론)을 참고하세요. 백업과 에셋에 서로 다른 서비스를 사용하려는 경우엔 방법이 없습니다(단, 한 버킷에서 다른 버킷으로 복제하는 트리거를 설정하는 방법은 존재합니다).

아니요, 백업용으로만 사용하고 싶어서, 내 네트워크의 다른 머신으로 자동으로 푸시되게 하고 싶어요.

그러면 제가 링크한 가이드가 바로 당신이 찾는 내용입니다.

1개의 좋아요

하루 한 번보다 더 자주 설정할 수 있나요? 추측을 하고 싶지 않아서 백업 주기를 float로 설정하는 편이 낫습니다.

1개의 좋아요

더 자주 백업을 원하신다면 외부에서 직접 수행하셔야 합니다.

3개의 좋아요