Restore a backup from command line

(Arpit Jalan) #1

Here’s how to restore a Discourse backup from the command line, without ever booting the Discourse web UI. This is handy when you’re moving servers.


  • Download the latest backup file from source Discourse instance.
  • Make sure that the destination Discourse instance is on the latest version. Update it if necessary.

Transfer Backup

SSH into the destination server, or otherwise create the backup folder there:

mkdir -p /var/discourse/shared/standalone/backups/default

Upload your backup file to the destination server.

scp /path/to/backup/backup.tar.gz root@

Of course, replace the above paths, filenames, and server names with the ones you are using – but you do want the backup file to end up in


:mega: You can also upload and download your Discourse backup file from popular web storage sites such as Google Drive, Dropbox, OneDrive, etc – you’ll need to look up the specific command line instructions based on your preferred web storage provider.

:warning: DO NOT CHANGE THE FILENAME OF THE BACKUP! Discourse treats the backup filename as metadata, so if you change the filename, restoring will not work. Stick with the original file name.

Replace /path/to/backup/discourse-xyz.tar.gz with the local path of your backup file, and replace <server_ip_address> with the IP address of destination server.

Restore Backup

Access your destination server and go to the Discourse folder

cd /var/discourse

Enter the Discourse Docker app container

./launcher enter app

From inside the Docker container, enable restores via

discourse enable_restore

Restore the backup file

discourse restore sitename-2019-02-03-042252-v20190130013015.tar.gz


After the restore process is complete rebuild the destination instance.

:mega: Now is a good time to update /var/discourse/containers/app.yml with full HTTPS, additional plugins or CDN configuration. Compare the app.yml configuration of both instances to make sure!

cd /var/discourse
./launcher rebuild app

:tada: That’s it. Your destination server is successfully restored.

Move your Discourse Instance to a Different Server
HELP! My Discourse just deleted everything?
How easy is it to move to another server?

What’s the best way to run these commands from outside the docker container? I am trying to set up a secondary failover server that automatically restores the latest database backup from the primary every week, then applies some custom site settings with Download and restore of site settings to make sure it is set read-only with email disabled until we need it.

I’ll use Running commands inside discourse container? as a starting point for my scripts, but it seems like ‘launcher exec’ is still a little rough around the edges.

1 Like
(Paul Solt) #3

After the restore, make sure to exit the docker app, otherwise your /var/discourse path won’t be there.

(Guilherme) #4

I’m seeing my backups inside the /var/discourse/shared/standalone/backups/default folder, but when I try to restore it I see a "no such file or directory"error. How can I fix it?
The name of the file is correct!

(Jay Pfaffman) #5


discourse restore

Inside the container wIth no filename. It will suggest the available filenames and you can then copy and paste.

(Guilherme) #6

None of the files appear, but all of them are inside the folder I’ve mentioned

(Gerhard Schlager) #7

Check the value of the backup_location site setting? It should be Local when you want to restore from the local file system. If it is, make sure that the backup files are readable by the discourse user inside the container.

(Jeff Atwood) split this topic #8

6 posts were split to a new topic: I can’t restore a backup from NodeChef

(Skygunner) #9

I guess its
discourse restore <filename.of.the.backup.tar.gz>


discourse restore sitename-2019-02-03-042252-v20190130013015.tar.gz

because the backup file name for me is something like

1 Like
(Keith John Hutchison) #10

Why is this step required?

(Stephen) #11

If you’ve cloned your old app.yml it isn’t.

But if you’re staging a copy to a different URL to minimise downtime then a rebuild is necessary to account for the final DNS name, certificates, etc.

(Keith John Hutchison) #12

The production site is not the latest version of the beta. Staging is currently the same version as production and I think ./launcher rebuild app would update the version on staging which I’d want to avoid until we’re ready to update production.

If the app.yml is mostly the same, a few settings like domain name being different and the plugins are the same, and rake sites_settings:export > settings.yml has been run on staging and rake sites_settings:import < settings.yml will be run after the restore can the rebuild step be ignored?

(Stephen) #13

Settings within the container will be in the backup.

If the containers are correctly configured for their purpose then you don’t need to more than restore the backup.

Your process differs because you’re doing something fundamentally different here. Some of these steps relate specifically to moving a site.