Restore a backup from command line

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

  • 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@192.168.1.1:/var/discourse/shared/standalone/backups/default

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

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

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

Exit the Discourse Docker app container

exit

Rebuild

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.

46 Likes

Since the replies are automatically deleted, I can share this little feedback.

I always use this method during a migration on a new server, never had an issue. It help save a few minutes, the command are really simple, the feedbacks during each steps are useful. Really good feature and guide.

Tonight, I had to restore a database from 2019 (the forum was closed for over a year). A lot happened in Discourse (back-end and front-end) since then, but it went smoothly, not even an tiny error. That’s cool.

11 Likes

Hello,

Thank you for the instructions. I tried two times migrate my Discourse to other server without success. How to do this if I use s3 assets?

How to create the backup files? I read somewhere:

  1. I should comment out the s3 lines in app.yml before make the backup.
  2. Restore on the new server from command line
  3. Update the app.yml and uncomment the s3 lines.
  4. Rebuild.

Is this correct? I try one more time today.

Should I comment out before backup these lines too? :arrow_down_small:

after_assets_precompile:
    - exec:
        cd: $home
        cmd:
          - sudo -E -u discourse bundle exec rake s3:upload_assets

And the DISCOURSE_CDN_URL: line?

Thank you for the answer! :slightly_smiling_face:

If you’re going to continue using the same S3 bucket to host media and backup after migration, simply create a backup without uploads and restore it to your new server, If you plan on switching your s3 provider, you may just use something like s3cmd to move all the media from one provider to the other and then do a discourse remap. If you plan to migrate assets to local storage, you may be out of luck since the migrate_from_s3 rake task is broken for a really long time and doesn’t work in most cases.

2 Likes

Yes I just going to use the same everything but other hosting provider. So just uncheck this option is enough?

Oh yeah i see in backup logs Skipping uploads stored on S3. :slightly_smiling_face:

Thank you!

2 Likes

This can be unchecked but FWIW when you click backup button on the backup tab, there is a choice Backup (do not include uploads) that should do the trick.

3 Likes