When invoking discourse backup, it creates an sql.gz file, which does not contain uploads. When creating a backup from the UI, there is an option to take it with the uploads. Is there a way to do a backup with uploads using the CLI?
סיכום מבוסס בינה מלאכותית
In a support thread titled “Discourse CLI - backup WITH uploads” tagged as unsupported-install, Marcin_J reports that running discourse backup via CLI only produces an sql.gz file, excluding uploads — despite having the backup_with_uploads site setting enabled and storing uploads locally. gerhard confirms no CLI flag exists for this but notes uploads should be included if the setting is active. After confirming uploads are not on S3 (Marcin_J), gerhard suspects configuration issues due to Marcin_J’s custom Kubernetes setup, suggesting possible missing environment variables or incorrect working directories — common in Bitnami and non-standard installs. pfaffman offers two workarounds: (1) migrate to a standard install, rsync images, then backup; or (2) run discourse backup inside a pod and manually copy the backup from /shared/backups/default to persistent storage — noting this works in GCP k8s. Marcin_J confirms backups are on a persistent Azure Files volume and reports that after resetting the deployment (forcing new pods), backups now correctly produce full tar.gz files — though the cause of the fix remains unknown. The thread highlights challenges with CLI backups in non-standard Kubernetes environments and the importance of persistent volume mapping for uploads.
There is no option for enabling it in the CLI right now, but it should include uploads when the backup_with_uploads site setting is enabled.
I have this setting enabled:
However, anytime I do discourse backup I get sql.gz.
Are your uploads stored on S3?
No, I store them locally.
Weird. Did you follow discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub when you set up your site?
No, my setup is rather custom, since I’m running Discourse on Kubernetes. However, my Discourse images (web and data) have been generated using the launcher script without any modifications.
Hmm, you are probably missing some env variable, or the working directory is wrong, or something like that. I’ve seen reports about similar issues from Bitnami installs. Unfortunately we can’t help you with that, you’ll need to figure this out yourself.
One way to do it might be to set up a standard installation, rsync the images (there a guides for moving to a new server), and then restore the backup. Then you could take a backup there.
If you have a budget, I might be able to help with your current setup Redirecting…
My guess is that you don’t have backups mapped to persistent space, so I think what you need to do is inside a pod, run discourse backup and then copy the backup file from /shared/backups/default inside that pod to outside of the pod. I’m pretty sure that’s what I do in the k8s setup that I have in GCP k8s (where you can’t use the buckets for backup because Google).
I do have backups on a persistent volume. I’m on AKS, and backups are on Azure Files.
I reset my deployment (forcing new pods to come up), and the backups are now “full” (tar.gz). I’ve no idea what has changed honestly.