Restore a backup from the command line

: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

Enable Email

When a backup is restored, outgoing mail for non-staff is disabled. You don’t want your test server, new server, or server that you just restored a backup for some other reason to start emailing your users! Change site setting “disable_emails” to re-enable email.

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

Last edited by @pfaffman 2025-05-18T19:32:40Z

Check documentPerform check on document:
「いいね!」 78

これらの手順でバックアップから復元できましたが、discourse restore コマンドを次のように変更する必要がありました。

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

(私の例では、上記の例のファイル名を使用しています)これにより、復元で /var/discourse/shared/standalone/backups/default ディレクトリに配置したバックアップ(s3に保存されていたバックアップとは対照的に)を見つけることができました。

「いいね!」 2

リストア後の再構築は必要ですか?

また、NGINXリバースプロキシがあり、それがアップストリームのDiscourseに渡される新しいサーバーにリストアしました。そのため、DiscourseのSSLを無効にしましたが、リストア中に次のメッセージに気づきました。

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

これはすべての内部リンクをリマッピングしていますか?これを元に戻すのは discourse remap http://example.com https://example.com と同じくらい簡単ですか?

いいえ。

そうみたいですね。はい、再マッピングできます。

force_https 変数を設定する必要があります。

「いいね!」 1

バックアップが15GBの場合、復元にはどのくらいのスペースが必要ですか?

「いいね!」 1

それはデータベースだけですか、それともアップロードもですか?

おそらくその3〜5倍でしょう。

「いいね!」 1

データベース+アップロードで15GB、60GBのHDに20GBの空き容量がありますが、毎回リストアが失敗します。リストアするには少なくとも50〜60GBの空き容量が必要ですか?

「いいね!」 1

バックアップ、アップロード、および非圧縮データベースのために十分なスペースが必要です。

最初にデータベースのみのバックアップを復元してから、rsyncで手動でアップロードをコピーすることを試すことができます。

「いいね!」 2

セルフホストで管理者アカウントを認証し、.tar.gz ではなく .sql.gz バックアップをアップロードしました。

UI での復元はうまくいかないため、コマンドラインから「バックアップを復元する」を実行しましたが、discourse restore プロセスの最後に [FAILED] と表示されました。公式ホスティングからの入力ファイルが .tar.gz であることが、プロセスを通過させる原因となる可能性がありますか?

私の公式ホスティングは数日前に開始したもので、セルフホストは container.yml で SMTP 値を変更した後、本日正常に動作し始めました (SMTP 値の変更)。

「いいね!」 1

エラーの内容を含める必要があります。ファイル名にはバージョン情報が含まれているため、ファイル名を変更した場合は、ファイル名の先頭の単語を変更するだけで、元の名前に戻す必要があるでしょう。

「いいね!」 1

discourse restore のドキュメントはどこかにありますか?--location local スイッチがあるようなので、S3用のものもあるのだと思います。

S3に保存されているバックアップからリストアしたいのですが、事前に手動でダウンロードする必要を避けたいです。

追記:気にしないでください。discourse restore --location s3 $filename は問題なく動作することがわかりました。

「いいね!」 2

app.yml で S3 を有効にしたため、純粋な discourse restore <filename> で問題なく動作しました。

backup restore s3 で検索すると、適切な投稿が見つかると思います。

「いいね!」 2

こんにちは、s3(-cli)scp として使用し、送信メールプロバイダーをMailGunからBrevoに変更してこのプロセスを完了しました。

リストア後、バナーを削除する方法が見つかりません。

バナーを削除する最も簡単な方法は、サイト設定でメールを有効にすることです。

「いいね!」 3

右。CSSで非表示にすることもできます!:joy:

「いいね!」 1

本当です。Air theme hides "outgoing email disabled" warning を思い出す必要があったため、少し慎重にこれをお勧めしました。

「いいね!」 1

**バックアップを復元するたびに、スタッフ以外のユーザーのメールは自動的に無効になります。**これは、テストサーバーに復元された後に、存在を知られるべきではないサーバーの通知をユーザーに大量送信し始めたため、コードに追加されたのだと想像します。

OPをそれに応じて更新しました。

「いいね!」 2

ハウツーの注記:

テスト目的で定期的にバックアップを復元し、テストサーバーが正しく設定されている場合、メールをデバッグメールサービス(GitHub - maildev/maildev: 📫 SMTP Server + Web Interface for viewing and testing emails during development. など)に送信するには、スクリプト経由でメールを有効にしたい場合があります。

docker exec -it app /bin/bash --login \
-c "rails runner 'SiteSetting.disable_emails=\"no\";'"

その場合、app.yml で DISCOURSE_DISABLE_EMAILS を no に設定することをお勧めします。(また、DISCOURSE_ENABLE_RESTORE も設定して復元を容易にしてください。)

「いいね!」 1