Restore a backup from the command line

Documentation Self-Hosting
1

:bookmark: This guide explains how to restore a Discourse backup from the command line without using the Discourse web UI.

:person_raising_hand: Required user level: Administrator

:wrench: Console access required

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.

Prerequisites

Before you start, make sure you complete the following steps:

  1. Download the latest backup file from the source Discourse instance.
  2. Bootstrap the destination Discourse instance by running ./discourse-setup or copying your existing app.yml.
  3. Ensure the destination Discourse instance is on the latest version. Update it if necessary.

Transfer the backup

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

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

  1. Upload your backup file to the destination server.

scp /path/to/backup/backup.tar.gz root@192.168.1.1:/var/discourse/shared/standalone/backups/default

Be sure to replace the paths, filenames, and server names with the ones you are using – but you do want the backup file to end up in:

/var/discourse/shared/standalone/backups/default

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

:bulb: If Nginx is used as reverse proxy make sure all paths to the backup are readable by the container and Nginx can read the .sock file.

Restore the backup

  1. Access your destination server and navigate to the Discourse folder:
cd /var/discourse
  1. Enter the Discourse Docker app container:
./launcher enter app
  1. Enable restore functionality:
discourse enable_restore
  1. Restore the backup file:
discourse restore sitename-2019-02-03-042252-v20190130013015.tar.gz
  1. Exit the Discourse Docker app container:
exit

Rebuild

After restoring the backup, you may choose to rebuild the destination instance to ensure all settings and configurations are applied correctly.

: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 Discourse server is successfully restored.

Last edited by @SaraDev 2024-08-23T20:49:40Z

Check documentPerform check on document:
76 Likes
59

These instructions worked for us to restore from backup, but we had to modify the discourse restore command to:

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

(my example uses the filename from the example above) to get the restore to find the backups that we had put in the /var/discourse/shared/standalone/backups/default directory (as opposed to backups that were stored on s3).

1 Like
60

Is the rebuild after restore necessary?

Also, I restored to a new server where there is an NGINX reverse proxy which then passes onto the upstream discourse. I therefore disabled SSL on discourse, but I noticed that during the restore:

Remapping 'https://example.com' to 'http://example.com'

Is this remapping all internal links? Is undoing this as simple as discourse remap http://example.com https://example.com?

61

No.

Looks like it. Yes you can remap them.

You should set the force_https variable.

1 Like
62

if backup is 15gb , how much space is needed to restore ?

1 Like
63

Is that just the database or uploads too?

Probably 3-5x that much.

1 Like
64

it is database+upload 15gb , i have 20gb space on 60gb HD but still restore fail each time , i need atleast 50-60gb space to restore ?

1 Like
65

You need enough space for the backup, the uploads, and the uncompressed database.

You might try to restore a database only backup first and then copy the uploads by hand with rsync.

2 Likes
66

I’ve verified my admin account on self host, and uploaded a .sql.gz backup, not a .tar.gz.

Restoring on the UI isn’t fruitful so i performed from “Restore the backup” at the command line, giving [FAILED] at the end of the discourse restore process, might the input file from an official hosting being .tar.gz cause process to pass?

My official hosting is a few days old, and my self host started working properly today after changing SMTP values in container.yml

1 Like
67

You’ll need to include what error you got. The filename has version in formation in it, though, so if you’ve renamed the file, you’ll likely need to name it back, changing just the words at the beginning of the filename.

1 Like
68

Is there a documentation for discourse restoresomewhere? as there seems to be a --location localswitch I assume there would also be one for S3?

I’m looking to restore from S3 located backups and avoiding having to download them manually beforehand.

EDIT: nvmd. I just found out that discourse restore --location s3 $filename seem to work just fine.

1 Like
69

Because I have enabled S3 in app.yml, just pure discourse restore <filename> worked just fine.

I think if you’ll seach for backup restore s3 you find the right post.

2 Likes