Target file directories to backup to ProtonDrive(besides R2 Media)?

Support
1

I am using Cloudflare R2 for media uploads but I believe it does not work for backing up the database. What file directories do I need to backup using rclone?

2

you may find the below topic helpful

Discourse file/directories to back up to ProtonDrive (besides R2/S3 media)

Step 1 — What upload:// means

upload://

Commentary

Discourse stores only the reference upload://<hash> in post content (raw/cooked). At bake time or when rendering, Discourse consults its database tables (like uploads, post_uploads, etc.) to resolve these hashes to actual URLs or paths based on where uploads are stored (local, CDN, S3/R2, etc).

Step 2 — Where that lands inside the container

/shared/uploads/default

Commentary

In the standard Docker install (using launcher and app.yml), /shared inside the container is bind-mounted from the host’s /var/discourse/shared/standalone. Everything persistent Discourse writes—including uploads, logs, backups, etc.—is under /shared.

Step 3 — The host filesystem path

/var/discourse/shared/standalone/uploads/default

Commentary

If you are not using external uploads (S3/R2), this is the main path you must sync to ProtonDrive to preserve uploaded post media. If you are using S3/R2, most uploads won’t be here, but some files (e.g., optimized variants, tombstones) may remain. Decide if you want to back this up as well.

Step 4 — The Docker volume mapping (app.yml)

volumes:

  • volume:
    host: /var/discourse/shared/standalone
    guest: /shared
Commentary

Everything in /shared inside the container becomes /var/discourse/shared/standalone on the host. If you back up this tree you get uploads, backup tarballs, logs, and (optionally) PostgreSQL data if kept on-disk (though the backup tarballs are generally sufficient for recovery).

Concrete targets to back up (local store)

Minimal set (if you trust Discourse’s tarball backups):

/var/discourse/shared/standalone/backups/ # Discourse-generated full backups (tarball .tar.gz files)
/var/discourse/shared/standalone/uploads/ # Only if you store uploads locally

Commentary
  • The tarball backup refers to the .tar.gz file created by the Discourse backup feature. It contains the entire database dump, site config, themes, and (optionally, if selected) all local uploads. It does not contain media stored on external S3/R2; only the database records referencing them.
  • If your uploads reside on S3/R2, you may only need /backups/ locally and a separate process to back up your object storage bucket.

“Everything I might ever need” set (filesystem-level copy):

/var/discourse/shared/standalone/backups/ # Full Discourse backups (tarballs)
/var/discourse/shared/standalone/uploads/ # Local uploads/media (if not S3/R2)
/var/discourse/shared/standalone/log/rails/ # (Optional) Rails logs—useful for forensics
/var/discourse/shared/standalone/tmp/backups/ # (Optional) transient backup staging (usually empty)
/var/discourse/shared/standalone/postgres_data/ # (Optional) raw PostgreSQL data directory—usually not necessary
/var/discourse/containers/ # Your app.yml and any container YMLs (configuration)
/etc/letsencrypt/ # (Optional) TLS certs if terminating SSL on host

Commentary
  • Raw PostgreSQL data is usually not required since the tarball backup contains a logical database dump, which is safer for restoration.
  • /containers is small but critical for disaster recovery—it holds your settings and volume mappings.
  • TLS certs only matter if you’re doing SSL outside the container.

Quick one-liner map

upload://
↓
/shared/uploads/default (inside Docker)
/var/discourse/shared/standalone/uploads/default (on host)

Commentary

If you use S3/R2:

  • Back up your S3/R2 bucket separately (e.g., with Rclone).
  • Still consider backing up /backups/ (tarballs, which include db and config, site uploads, but not external media) and /containers/.

:white_check_mark: TL;DR for the ProtonDrive thread

  • Local uploads? Back up:
    • /var/discourse/shared/standalone/uploads/
    • /var/discourse/shared/standalone/backups/ # (contains tarball backups as .tar.gz)
  • S3/R2 uploads? Back up:
    • /var/discourse/shared/standalone/backups/ # (tarball backups: db/config/uploads table)
    • Your S3/R2 bucket with another tool
    • Optionally: /containers/, /log/rails/, and postgres_data for full DR coverage
Commentary

Tarball backup: The .tar.gz file created by Discourse’s backup system, holding a logical database dump, themes, configs, and (optionally) local uploads, but never includes external S3/R2 media.

3

i would like to highlight that each of the 3 times i’ve moved server, relying on tarball backup to preserve local uploads, the default app.yml has been different

Therefore, it’s probably better to manually copy-over parts of the old app.yml to replace parts of the new file.

4

So, how do i get that out of the Container?

i’d like to try docker cp for getting a tarball backup file out of a discourse container and onto the host system, if that’s necessary

  • The basic syntax is: docker cp [SOURCE_PATH] [CONTAINER_NAME]:[DEST_PATH] and vice versa.