コマンドラインからバックアップを復元する

[Discourse]

このガイドでは、Discourse の Web UI を使用せずに、コマンドラインから Discourse のバックアップを復元する方法を説明します。
必要なユーザーレベル: 管理者
コンソールアクセスが必要です

ここでは、Discourse の Web UI を起動することなく、コマンドラインから Discourse のバックアップを復元する方法を説明します。これは、サーバーを移行する際に便利です。

前提条件

始める前に、次の手順を完了していることを確認してください。

1. ソースの Discourse インスタンスから最新のバックアップファイルをダウンロードします。
2. ./discourse-setup を実行するか、既存の app.yml をコピーして、宛先の Discourse インスタンスをブートストラップします。
3. 宛先の Discourse インスタンスが最新バージョンであることを確認します。必要に応じて更新します。

バックアップの転送

1. 宛先サーバーに SSH 接続するか、そこにバックアップフォルダーを作成します。

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

2. バックアップファイルを宛先サーバーにアップロードします。

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

パス、ファイル名、サーバー名を、使用しているものに置き換えてください。ただし、バックアップファイルは次の場所に配置する必要があります。

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

Google Drive、Dropbox、OneDrive などの一般的な Web ストレージ サイトから Discourse のバックアップファイルをアップロードおよびダウンロードすることもできます。好みの Web ストレージプロバイダーに基づいて、特定のコマンドライン手順を確認する必要があります。

バックアップのファイル名を変更しないでください! Discourse はバックアップファイル名をメタデータとして扱うため、ファイル名を変更すると復元が機能しなくなります。元のファイル名を維持してください。

/path/to/backup/discourse-xyz.tar.gz をバックアップファイルのローカルパスに置き換え、\u003cserver_ip_address\u003e を宛先サーバーの IP アドレスに置き換えます。

Nginx をリバースプロキシとして使用している 場合は、すべてのバックアップパスがコンテナによって読み取れ、Nginx が .sock ファイルを読み取れることを確認してください。

バックアップの復元

1. 宛先サーバーにアクセスし、Discourse フォルダーに移動します。

cd /var/discourse

2. Discourse Docker アプリコンテナに入ります。

./launcher enter app

3. 復元機能を有効にします。

discourse enable_restore

4. バックアップファイルを復元します。

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

ヒント: ファイル名を指定せずに discourse restore を実行すると、利用可能なすべてのバックアップファイルが一覧表示されます。

サイトの backup_location 設定が S3 を使用するように構成されているが、バックアップファイルをローカルファイルシステムに手動でアップロードした場合は、--location local を指定する必要があります。

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

同様に、ダウンロードせずに S3 バックアップから直接復元するには、--location s3 を使用します。

5. Discourse Docker アプリコンテナを終了します。

exit

リビルド

バックアップを復元した後、すべての設定と構成が正しく適用されていることを確認するために、宛先インスタンスをリビルドすることを選択できます。

ここで、/var/discourse/containers/app.yml を完全な HTTPS、追加のプラグイン、または CDN 構成で更新する良い機会です。両方のインスタンスの app.yml 構成を比較して確認してください!

cd /var/discourse
./launcher rebuild app

Eメールの有効化

バックアップが復元されると、スタッフ以外のユーザーの送信メールが無効になります。テストサーバー、新しいサーバー、または何らかの理由でバックアップを復元したばかりのサーバーがユーザーにメールを送信し始めることは望ましくありません。disable_emails サイト設定を「no」に変更して、メールを再度有効にします。

これで完了です。Discourse サーバーは正常に復元されました。

[gregcaporaso]

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

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

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

[Isambard]

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

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

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

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

[pfaffman (Jay Pfaffman)]

@Isambard

Is the rebuild after restore necessary

いいえ。

@Isambard

Is this remapping all internal links?

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

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

[pinder99 (Pushpender Singh)]

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

[pfaffman (Jay Pfaffman)]

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

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

[pinder99 (Pushpender Singh)]

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

[pfaffman (Jay Pfaffman)]

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

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

[Ethsim2 (Ethan)]

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

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

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

[pfaffman (Jay Pfaffman)]

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

[helmi]

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

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

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

[Jagster (Jakke Flemming)]

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

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

[Ethsim2 (Ethan)]

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

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

[Moin]

@Discourse

復元プロセスでは、disable emails 設定が自動的に「non-staff」に設定されるため、準備ができるまでサイトのユーザーにメールが送信されることはありません。

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

[pfaffman (Jay Pfaffman)]

@Moin

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

右。CSSで非表示にすることもできます！

[Moin]

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

[pfaffman (Jay Pfaffman)]

@Moin

私はこれを推薦することに少し慎重でした。なぜなら、Air theme hides "outgoing email disabled" warningのことを考えなければならなかったからです。

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

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

@Discourse

メールを有効にする

バックアップが復元されると、スタッフ以外のユーザーの送信メールが無効になります。テストサーバー、新しいサーバー、またはその他の理由でバックアップを復元したばかりのサーバーがユーザーにメールを送信し始めることを望まないでしょう！メールを再度有効にするには、サイト設定「disable_emails」を変更してください。

[thoka (Thomas Kalka)]

ハウツーの注記：

テスト目的で定期的にバックアップを復元し、テストサーバーが正しく設定されている場合、メールをデバッグメールサービス（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\";'"

[pfaffman (Jay Pfaffman)]

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