Discourse の皆様、こんにちは。
昨夜、Discourse のアップグレードを進めてアプリを再構築したところ、Postgres のエラーが多数発生しました。これは最近のアップグレードが原因だと気づいたものの、「Permission denied」エラーなど、さまざまな問題に直面しました（はい、すべての権限を 700 に変更して chown しましたので、グローバルな設定ではありません）。そのため、元の /var/discourse を一時的な場所に移動し、Postgres を少なくとも最新の状態にしようと、Discourse の新しいインスタンスを再インストールしました。
ここからが面白い話です。UI 経由で 3 日前に作成したサイトのバックアップ（データベースのみ。アップロードは別のボリュームに保存されています）があったはずです。少なくとも、そう思っていました。しかし、手元にあるのは wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz というファイルで、これは実際のバックアップが入っているべき tar.gz ファイルではないと、今になって学びました。
現在は全ユーザーをランディングページにリダイレクトしています。サーバーから 3 日前の実際の .tar.gz ファイルを復元できるかどうか、そして具体的にどうすればよいかを教えてください。
バックアップとアップロードは Digital Ocean のブロックストレージに保存しており、以前機能していた古いインストールの discourse フォルダも手元にあります。しかし、それを /var/discourse に戻したりコピーしたりすると、Postgres エラーを含むすべての問題が再発してしまいます。9 時間ずっとこの問題に取り組んでおり、もう限界です。どなたか助けていただけないでしょうか、あるいは少なくとも正しい方向へ導いていただけないでしょうか？
先ほど 1,000 ユーザーを達成したばかりなので、それを失うことはどうしても避けたいのです。
編集：アップロードの設定について補足しました。
pfaffman
(Jay Pfaffman)
2
app.yml に S3 設定が含まれている場合、コマンドラインから復元を実行するだけで、S3 からバックアップを自動的に取得できます。
アセットが S3 に保存されているため、バックアップにはデータベースのみが含まれます。
新しい /var/discourse をクローンし、yml ファイルをコピーして再構築し、コマンドラインから復元を実行するだけで問題なく動作するはずです。
アップロードにオブジェクトストレージを使用する（S3 とクローン）
コマンドラインからバックアップを復元する
私のバックアップやアップロードの設定方法について、適切な用語を使っていなかったようです。私はこの方法を使用しました: Move Uploads and Backups to DigitalOcean Block Storage
訂正しますと、私のアップロードとバックアップはメインの Discourse フォルダのローカルには保存されていません（この問題の発端は、DigitalOcean Spaces への移行を試みていたことです）。したがって、残念ながら S3 設定は行われておらず、マウントされたストレージに保存するだけでした。
バックアップは mnt/my_storage/shared/standalone に保存されていましたが、その場所を確認すると、wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz ファイルしかありません。他に手がなかったため、実際にそのファイルから復元を試みました（おそらく間違いでしたが）、権限拒否のエラーが発生しました。これはおそらく、バックアップが実際にどのように生成されているかに関係しているのでしょう。
RGJ
(Richard - Communiteq)
4
アップロードデータはまだDOのブロックストレージにありますか？
RGJ
(Richard - Communiteq)
6
OK、大丈夫です。
その場合、SQL ファイルを復元し、その後ブロックストレージボリュームを再度マウントすれば、アップロードデータを復元できます。
バックアップには 2 種類あります。sql.gz はアップロードデータを含みませんが、tar.gz はアップロードデータを含みます。つまり、間違った種類のバックアップを選んでしまいましたが、アップロードデータを外部ボリュームに保存していたことが、あなたを救いました。
「いいね！」 2
アプリにアクセスしてその sql.gz を復元しようとしましたが、権限が拒否されました。その理由が何か分かりますか？
まさにその通りです！ 
RGJ
(Richard - Communiteq)
8
（おそらく chmod のことをおっしゃっているのでしょう）ファイルの所有者が正しく設定されていない場合、書き込みできません。
これが「アクセス拒否」の原因だった可能性があります。
正確なエラーメッセージは何ですか？
はい、ありがとうございます。一晩中起きていて、頭が少し回っていません。
例外: lib/discourse.rb:93:in `exec': アーカイブを tmp ディレクトリにコピーできませんでした。
cp: '/var/www/discourse/public/backups/default/wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz' を読み込めません: 権限がありません
RGJ
(Richard - Communiteq)
10
chmod 644 /var/www/discourse/public/backups/default/*を実行してください
「いいね！」 2
わかりました、今から対応しています。すぐにご報告します。お時間を割いてお手伝いいただき、ありがとうございます。
これでリストアが開始されました。ありがとうございます。
さて、なぜまだサイトが読み込まれないのかを解決する必要があります。
現在、破損する前に保存していた app.yml ファイルを使って再構築を進めています。
「いいね！」 1
このバックアップをアプリに直接移動させるコマンドはありますか？復元機能が見つからず、以前どのようにして読み込んだか思い出せません。
pfaffman
(Jay Pfaffman)
13
S3 からダウンロードして、以下の場所に配置してください。
/var/discourse/shared/standalone/backups/default
コマンドラインから復元できるはずです。
その後、上記のリンクに記載されている方法で S3 設定を構成してください。そうすると作業が楽になります。
「いいね！」 2
ありがとう、ジェイ。ええ、それは確かに私の計画通りです。
「いいね！」 1
さて、今の状況をお伝えします。
- その .sql.gz ファイルからのリストアは成功しました（やった！リチャードさん、改めてありがとう）。
- app.yml がすべて壊れる前の設定と同じになっていることを確認しました。
./launcher rebuild app を実行しました。- PostgreSQL 13 でのビルドが成功しました（やっと！）。
しかし、サイト自体へのアクセスは依然としてできません。Cloudflare を使用していますが、現在は開発モードをオンにしており、DNS キャッシュもクリアしました。すべての設定は正しい場所を指しています。Cloudflare のテンプレートは app.yml に含まれています。
DNS の解決は正しく行われ、ホスト名も最新の状態です。Discourse のインストールも適切な URL で行われましたが、もう手がかりがなくなっています。
https://forum.wackywriters.com という URL ですが、「サーバーが利用できません」というエラーが表示されるだけです。まるで堂々巡りになっているようです（すみません）。何かアドバイスはありますか？
編集：./discourse-doctor を実行すると、Docker 内にアプリのインスタンスが 2 つ実行されていることがわかりました：
これは正常でしょうか？（普通はそうではないと思いますが、過去 24 時間で Discourse について知っていたことがすべて覆されてしまいました 
）
編集2：最後の手段として先延ばしにしていましたが、完全に新しいサーバーをセットアップしてクリーンな Discourse インストールを試みることにします。私の手荒な操作のせいで何かがおかしくなっているのではないかと心配で、何が壊れているのか見当がつかないのです。幸い、バックアップとブロックストレージ上のすべてのアップロードデータは残っています。運が良ければ、それを新しいドロプレットに接続し、そこからデータを移行できるはずです。追加のアドバイスやコツがあれば、私の経験よりも豊富な知見を持つ方からの意見をいただければ幸いです。
編集3：新しいサーバーと IP のプロパゲーションが行われているにもかかわらず（nslookup と ping はどちらも良好、whatsmydns.net も問題なし）、フォーラムは読み込まれません。依然として接続エラーが発生しています。IP アドレスが Discourse インスタンスに接続されていないのではなく、静的ページを読み込もうとしているように見えますが、もちろんこの場合、そのようなページは存在しません。
ほぼ24時間にわたる格闘の末、復旧作業を開始した後、サイトが読み込めなくなった理由がわかりました。
無数のリセットと再インストール、そして神のみぞ知る他の作業の結果、レート制限に達してしまいました。そのため、一時的にSSLテンプレートをコメントアウトし、1週間後に再度有効にする予定です。
破損した画像を修正するためにすべての投稿を再構築している間、サイトは「機能」していますが、今日助けてくれたJayとRichardには本当に感謝しています。私がどうしても解決できなかった部分を乗り越えることができました。
さて、今週中にS3を設定し、また同じ問題に直面しないようにするために、本当に信頼できるバックアップをダウンロードする番です。
「いいね！」 1
pfaffman
(Jay Pfaffman)
18
検索すれば、Let’s Encrypt に対して別リクエストとしてカウントされるように、2 番目のドメインを追加する方法があります。ただし、待機する方が簡単です。
Cloudflare のプロキシ設定をグレークラウド（プロキシ無効）にし、速度向上機能を無効にすることをお勧めします。
「いいね！」 1
RGJ
(Richard - Communiteq)
19
@pfaffman オブジェクトストレージとブロックストレージを混同していませんか？オブジェクトストレージは S3 ですが、TS はブロックストレージを使用したと述べています。これはアップロードディレクトリにマウントされたディスクに過ぎません。
「いいね！」 1
pfaffman
(Jay Pfaffman)
20
ああ。
そうか。つまり、私が言ったことはすべて意味をなしていないわけだ。
そのことに気づいてくれてありがとう、リチャード。
「いいね！」 2
RGJ
(Richard - Communiteq)
21
いえ、あなたが言ったことの「ほとんど」は意味が通じていたんです。ただ、ここで少し混乱させてしまったみたいですね
「いいね！」 2
