/var/discourse アプリフォルダ全体のバックアップと復元方法

/var/discourse フォルダ全体をバックアップして復元するには?

通常のバックアップと復元プロセスに 問題 があるため、/var/discourse フォルダ全体をバックアップし、別のサーバーで再利用できるか疑問に思いました。私が行った手順は以下の通りです…

本番サーバー上:

rsync_opts="\
   --recursive \
   --links \
   --hard-links \
   --safe-links \
   --owner \
   --group \
   --perms \
   --times \
   --delete \
   --sparse \
   --compress \
   --partial \
   --rsh=ssh
"
dir=/var/discourse
rsync  $rsync_opts "$dir/" root@xx.xx.xx.xx:"/var/production-backup/$dir"

ステージサーバー上:

Docker をインストールします。

rsync --recursive --links --hard-links --safe-links --owner --group --perms --times --delete --sparse --compress --partial /var/production-backup/var/discourse/ /var/discourse

しかし、502 Bad Gateway エラーが発生します。

調査中です。

cd /var/discourse

./launcher start app

root@whonix-app:/var/www/discourse# service postgresql status
12/main (port 5432): down
root@whonix-app:/var/www/discourse# service postgresql start
[....] Starting PostgreSQL 12 database server: main[....] Error: The cluster is owned [FAILoup id 116 which does not exist ... failed!
 failed!

いくつかの修正を試みます:

chown -R postgres.postgres /etc/postgresql
chown -R postgres.postgres /shared/postgres_*
chown -R postgres.postgres /var/lib/postgresql
chown -R postgres.postgres /var/log/postgresql
chown -R redis.redis /etc/redis/redis.conf
chown -R redis.redis /shared/redis_data
chown -R redis.redis /var/run/redis
chown -R redis.redis /var/lib/redis
chown -R redis.redis /var/log/redis
chgrp -R ssl-cert /etc/ssl/private

しかし、効果はありませんでした。

root@whonix-app:/var/www/discourse# service postgresql start
[....] Starting PostgreSQL 12 database server: main[....] Error: /usr/lib/postgresql/12/bin/pg_ctl /usr/lib/postgresql/12/bin/pg_ctl start -D /shared/postgres_data -l /var/log/postgresql/postgresql-12-main.log -s -o -c config_file="/etc/postgresql/12/main/postgresql.conf" exited with status 1: 2020-05-25 10:20:10.501 UTC [603] FATAL: database files are incompatible with server 2020-05-25 10:20:10.501 UTC [603] DETAIL: The data directory was initialized by PostgreSQL version 10, which is not compatible with this version 12.2 (Debian 12.2-2.pgdg100+1). pg_ctl: could not start server Examine the lo[FAILput. ... failed!
 failed!

なぜこれらのファイル権限の問題が発生するのでしょうか?

なぜ、単にフォルダ全体をあるサーバーから別のサーバーにコピーしただけで、PostgreSQL がバージョン 10 からバージョン 12 に更新されるのでしょうか?何か間違ったことをしているはずです。

1 つのサーバー上の Discourse アプリ全体をバックアップし、別のサーバーに移行する方法について、手順をご教示いただけますでしょうか?

Discourse は Phabricator を使用していませんか?

「いいね!」 1

タイプミスです。Discourse と言いたかったです。タイプミスを修正しました。元の質問はそのままです。

「いいね!」 2

それは /var/discourse フォルダ全体を移動するものではありません。私はこれらの手順を知っていますが、これらは私の環境では 機能しません。そのため、より「完全な」1対1の「ハードコピー」方式でバックアップを取りたいと考えていました。

コンテナをシャットダウンし、tmp、backup、cache ディレクトリ(そして、もう一つあったような気がするのですが?)を除いて、すべてを新しいサーバーにコピーできます。それで問題ないはずです。私も最近、似たような理由でこれを行いました。

ただし、壊れたインデックスの問題を解決する必要があります。

「いいね!」 2

Docker のバージョンが違いを生み出していると思います。(それが失敗につながっています。)

元のサーバー
docker-engine 17.05.0~ce-0~debian-stretch

対 新バージョン(ステージ)サーバー
docker-engine 17.05.0~ce-0~debian-stretch

その結果、元のサーバーでは PostgreSQL バージョン 10 であるのに対し、新バージョン(ステージ)サーバーでは既に PostgreSQL 12 になっています。

これは必須ですか?もっと簡単な方法はありませんか?なぜすべてをそのままコピーして復元してはいけないのでしょうか?

これにより説明のつかない権限の問題が発生しました。権限を壊さずにコピーできるはずです。また、すべての権限問題を完全に修正したかも確信が持てません。

はい、しかし今は少なくとも現在動作しているものを再現できるようになってから、それに取り組む方がずっと安全だと思います。

/var/discourse ディレクトリを単に「tar 化」して別のマシンへ移動し、untar して Discourse アプリを起動することはできません。

主な理由の一つは、Discourse をビルド/ブートストラップする際、(私の記憶ではランチャーが)基本となる Discourse コンテナ(イメージ)が存在するか確認し、存在しない場合は基本となる Discourse Docker イメージをプルして、そのイメージをコンテナとして起動する点です。

その後の基本 git プルにより、ビルドプロセスは別の Docker イメージ(アプリ)を構築します。

これらの 2 つの Docker イメージ(基本イメージとアプリイメージ)は /var/discourse 内には存在しないため、/var/discourse を tar 化しても部分的な「解決策」(この用語を緩く使っています)に過ぎません。

これらの Discourse Docker イメージは Docker イメージとして構築され、Docker の一部として扱われます。それらは /var/discourse に「存在」するのではなく、そこで構築された後に Docker イメージとして Docker へ移動されます。

コンテナの yml ファイルを編集してゼロから再構築することも可能かもしれませんが、より一般的な方法は、以下のファイルを保存することです。

  • コンテナの yml ファイル
  • アップロードを含む完全なバックアップ

その後、コンテナの yml ファイルを編集し、discourse-docker リポジトリをクローンして再構築します。

そして、コマンドライン(コンテナ内)からアップロードを含む完全なバックアップを復元します。

リポジトリとして GitHub を使用する方法は、古い「unix 的」な「全体を tar 化」して「全体を別のサーバーへ移動」する方法よりもクリーンな解決策です。ただし、この「古い unix 方式」でも、システム内の共有ライブラリ、共有ライブラリのユーザーディレクトリ、配布ディレクトリに含まれないファイル、ディストリビューションのルートディレクトリにない etc ファイルなどがあるため、完全な解決策とならないことがよくあります。

したがって、最新の Linux システムでも、リポジトリをプルするために apt(Ubuntu の場合など)を使用します。Discourse Docker の場合は、基本コンテナを設定するために discourse-docker をプル(およびビルド)し、アプリを構築するために別の discourse リポジトリを使用します。つまり、/var/discourse は(イメージを構築する)「構築場所」と、(データ、バックアップ、公開静的ファイルなど)を共有する「共有場所」です。

この要約が少しでもお役に立てば幸いです。

「いいね!」 2

はい、rsync -rav ですべてコピーできます。

Postgres 10 のテンプレートを使用するようにアプリを変更すると、うまくいくかもしれません。ただし、最も簡単な方法は、データベースをその場で修正することかもしれません。

「いいね!」 4

フォルダを移動させることは可能で、問題なく動作します。ただし、discourse-setup やその実行中に実施されるチューニングやテストを回避することになるため、推奨される方法ではありません。

「いいね!」 2

私の場合、動作しませんでした。アップグレードされた Docker が Docker コンテナ内で新しい Postgres バージョンを起動し、Postgres のマイグレーション問題によりフォーラムが使用不能になったためです。Postgres 10 のテンプレートに変更する必要がありました。

How to backup and restore a whole /var/discourse app folder? - #8 by neounix に詳しい説明があります。

/var/docker フォルダもバックアップして復元する必要があるかもしれません。しかし、それさえも以下の理由で失敗する可能性があります。

あなたはトンネルを掘り進んでいます。
もし私があなたなら、バックアップとリストアの元の課題に集中するでしょう。

「いいね!」 4

もしかしたら :rat: :rat: :rat: の穴かもしれませんね。

同意します……間違いなく……

@adrelanos

バックアップ/リストアのプロセスに「問題」はありません。数ヶ月前に私 @neounix がこのトピックについて書いたこの「称賛」をご覧ください:

「いいね!」 1

@adrelanos

上記の投稿 #1 にあるご質問に戻りますが、好奇心から、以前の回答には満足できず、本日いくつかのテストを行いました。

要約すると、ベースコンテナとアプリコンテナには docker save を、/var/discourse ディレクトリには tar を使用することで、アプリを完全に保存(バックアップ)、転送、復元できることを確認しました。

この方法は「公式にサポートされている」ものではないとほぼ確信していますが(99.99%)、ご質問への回答が必要とのことで、テストを行いました。

基本的な手順の概要は以下の通りです。

  1. docker save でコンテナを保存します。

例えば、スタンドアロンのアプリを稼働している場合、設定に応じてベースとアプリのコンテナを以下のように保存できます。

docker save -o /tmp/my.discourse.docker.app.tar  discourse/base:2.0.20200512-1735

また、

docker save -o /tmp/my.discourse.docker.app.tar local_discourse/app:latest  
  1. ご指摘の通り、/var/discourse ディレクトリを tar アーカイブにすることも可能です。
cd /var/
tar -cvzf /tmp/my.var.discourse.tar.gz discourse

必要であれば、docker の tar ファイルを gzip 圧縮してアーカイブすることもできます。

gzip /tmp/my.discourse.docker*.tar
  1. … これらのファイルを別のサーバーに移動したり、同じサーバー上でアーカイブしたり、好きなように処理した上で、手順を逆転させれば、問題なく Discourse アプリを再起動できます。

私は実際に実行し、すべてのコンテナイメージと /var/discourse ディレクトリを削除することでこれを確認しました。つまり、すべてを消去して、ドメイン名などが変わらないため再構築の必要もなく、バックアップから再起動しました。

例えば、復元する場合は、上記で保存した docker イメージを読み込みます。

gzip -d /tmp/my.discourse.docker.app.tar.gz
docker load -i /tmp/my.discourse.docker.app.tar

gzip -d /tmp/my.discourse.docker.base.tar.gz
docker load -i /tmp/my.discourse.docker.base.tar
  1. 次に、元の /var/discourse ディレクトリを解凍します。
cd /var
tar -xvzf /tmp/my.var.discourse.tar.gz
  1. 次に、イメージが適切にラベル付けされているか確認します。
docker images
  1. イメージのラベルが適切でない場合は、正しいタグを付けます。例えば、アプリイメージの場合:
docker tag 58ffc74989af local_discourse/app:latest
  1. 最後に、以下を実行します。
cd /var/discourse
./launcher start app

これで問題なく動作します。私はこれを(2 回)テストしました。

ご参考になれば幸いです。

参考までに:この方法は 2 通りの方法で試しました。上記のバックアップ手順を実行し、すべての docker コンテナ、イメージ、および /var/discourse ディレクトリを消去(毎回完全に破壊)しました。

いずれの場合も、保存した docker イメージを読み込み、/var/discourse ディレクトリを解凍し、./launcher start app を実行すると、Discourse は問題なく起動しました。その証拠として、UI から「通常のバックアップ」を実行でき、すべて正常であることを確認しました。

これがご質問への回答になっているか分かりません(Postgres 10 から 12 へのアップグレードや議論には参加しておりません)が、アプリを単に tar でアーカイブしてバックアップし、復元するというご質問に対しては、はい/var/discourse ディレクトリをアーカイブするだけでなく、イメージも docker save で保存する必要があります。

最大の注意点(落とし穴)は、イメージのリポジトリ名とタグを正確に保つことです。そうすれば問題なく動作します。

ご質問の「/var/discourse アプリフォルダ全体をバックアップして復元するには?」という点について、少しでもお答えできれば幸いです。

答えは、上記の例のように、イメージには docker save(バックアップ用)と docker load(復元用)を使用し、フォルダと docker イメージの両方をアーカイブする必要があるということです。

この方法は公式にはサポートされていませんが、好奇心からシステム管理者の視点でどう行うか調べてみたところ、以前の回答で示唆していたよりも簡単であることが分かりました。

注1:

/var/discourse/ ですべてを tar アーカイブする前に、backups/default ディレクトリからすべてのバックアップを(ディレクトリツリーの外へ)移動させ、それらのバックアップを(別途)保持しておくことをお勧めします。これらのファイルは非常に大きいためです…

注2:

この種類のバックアップはサポートされていないため、ほとんどの Discourse システム管理者には推奨されません。ユーザーには、推奨され(かつ公式にサポートされている)Discourse のバックアップおよび復元方法に従うことをお勧めします。

好奇心を持ってください!

お気をつけて。____

詳細(スクリーンショットを含む)については、私の完全な投稿をこちらでご覧ください:

「いいね!」 6

素晴らしいアプローチですね!ありがとうございます!

復元サーバーで一つ問題が発生しました。

./launcher logs app

2020-06-18 13:33:56.434 UTC [127] FATAL: data directory “/shared/postgres_data” has wrong ownership
2020-06-18 13:33:56.434 UTC [127] HINT: The server must be started by the user that owns the data directory.
./run: 3: echo: echo: I/O error
2020-06-18 13:33:57.448 GMT [128] LOG: skipping missing configuration file “/shared/postgres_data/postgresql.auto.conf”


これは tar のオプションが不足していることが原因かもしれませんか?抽出時に -p-s を追加しましたが、効果はありませんでした。

元のサーバー(Docker 外):

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 4096 May 25 13:16 base

元のサーバー(Docker 内(./launcher enter app)):

ls -la /var/lib/postgresql/10/main/

drwx------ 5 root postgres 4096 May 25 23:28 base


復元サーバー(Docker 外):

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 71 May 25 11:16 base

復元サーバー(Docker 内):

drwx------ 5 root postgres 41 May 25 23:28 base


./launcher rebuild app で解決するかもしれませんが、それは本題から外れます。

何かご存知ですか?

復元プロセスに基づくと、docker save -o /tmp/my.discourse.docker.base.tar discourse/base:2.0.20200512-1735 のことをおっしゃりたいのだと思います。いずれにせよ、詳しいご説明ありがとうございます!

ただ、おっしゃる通り、これは公式にサポートされたアプローチではないと思います(ただし、Discourse チームが再構築プロセスで 1 つ以上のベースイメージを使用し始める限り、他にエラーの原因となる要素はないとも思いません)。

同じ問題が以下でも発生しているようです:

https://meta.discourse.org/t/postgresql-12-update/151236/298?u=lucasbasquerotto

FAQにはこの特定の課題に対する明確な回答はありませんが、複数人が同様の問題に直面していることを踏まえ、Discourse チームが解決策を追加する可能性があります。ソースクラスタが正常にシャットダウンされなかった に関する FAQ は、あなたの問題に関連している可能性があります。

「いいね!」 1

docker save や /var/discourse のまるごと tar+untar を使わない方法: