バックアップ用 tar ファイル内で編集すべきファイルについて、ご教示いただけますでしょうか？
アーカイブ内に dump.sql が含まれています。これを修正し、修正版を再度アーカイブに圧縮して戻す必要があります。私もこのファイルを修正することで他の問題も解決しました。ログイン後にクラッシュを引き起こしていた不正なカスタムフィールドを削除しました。
ありがとうございます。
指示に従って、バックアップをダウンロードし、解凍してそのファイルを変更してみます。
バックアップを復元するために、これほど多くの作業が必要なのは少し怖いですね。
これは新しいリリースのバグではないでしょうか。
しかし、バックアップと復元は災害復旧計画の要です。
これらは可能な限り堅牢であるべきであり、そのプロセスにバグがあると、大きな影響を及ぼします。
「いいね！」 1
さて、バックアップファイルを変更せずにリストアができました。
何度か試してみましたが、不思議なことに、そのうちの一度はエラーなしでリストアが完了しました。
Discourse から追い出されてしまい、ランチャーの再構築アプリを作成するまで機能しませんでした。
しかし、現在は正常に動作しています。
奇妙な問題ですね。
バックアップからのフォーラム復元がまだうまくいきません。数週間経っても、バックアップからの復元機能は依然として機能していないようです。
何か解決策はありますか？
私の知る限りでは、更新とテーブルのフォーマット確認を交互に行い、ソースとホスト間ですべてが一致しているか確認し、何度も失敗を繰り返しながら進める必要があります。その過程で、多少のデータベース編集を伴わずにうまくいく場合もあれば、いかない場合もあります。
3 つのサイトのうち 2 つの移行には成功しましたが、精神衛生上、1 日 1 時間未満しかこの作業に割くことができません。将来的に同様の状況で問題が生じる可能性があるため、クライアントとも話し始めています。肩をすくめる
私は単に復元を堅持し、それが機能するまで続けました。
エラーは、ユーザープロフィールテーブルに存在しない列について報告しています。
しかし、これはデータベース側のタイムアウトエラーか、あるいは PostgreSQL 側のバグかもしれません。列が存在しない場合、復元を繰り返し行っても自動的に作成されることはありません。
Jaromir 氏は、スクリプトを変更することで問題が解決すると述べています。
Discourse の開発者からはこの問題について懸念を示す声は聞こえてきませんが、これは奇妙で非常に不安を招くエラーであり、災害復旧計画に影響を及ぼすものです。
もしかすると、このトピックは他のトピックの中に埋もれて見過ごされているのかもしれません。
見逃してはいません。明日、真っ先に確認します。
また、バックアップとリストアの改善に取り掛かり始めています。災害時や単に新しいサーバーへの移行時などに、これらのことで心配する必要が誰にもないようにするためです。
「いいね！」 11
ありがとうございます。そう聞いて嬉しいです。
ありがとう、ゲルハルト。今は気にしていないかもしれないが、GCP で PG 11 を使用しているサイトでも同様の問題が発生している。PG 12 への移行は今年の秋に行われる予定と伺っているが、その影響も懸念されるので、確認してみる価値があるかもしれない。
S3 バックアップバケットを共有する 2 つのインスタンスをアップグレードした。一方のインスタンスでバックアップを実行し、他方で復元を試みたところ、以下のエラーが発生した。
No migration with version number 20191007140446.
PostgreSQL 11 および 12 は現在サポートされていません。
「いいね！」 4
はい、最新の Discourse バージョン（tests-passed）を Droplet にインストールし、バックアップの復元（S3 は使用せず、アップロードファイルも含まれます）に問題なく成功しました。
復元中に引き続き問題が発生する場合は、以下の手順を実行してください。
-
コンテナの再構築:
cd /var/discourse git pull ./launcher rebuild app -
ウェブインターフェースまたはコマンドラインからバックアップを復元:
cd /var/discourse ./launcher enter app discourse enable_restore discourse restore <filename>
動作しない場合は、復元しようとしているバックアップファイルのバージョン番号と、復元中に表示されるエラーメッセージを併せて投稿してください。
「いいね！」 6
両方のサイトは 2.4.0.beta6 (8fc0cc9aaa) です。バックアップ（アップロードは除く）は S3 に保存されています。
discourse restore の出力は以下の通りです。
Starting restore: wonderful-community-2019-10-10-184822-v20191007140446.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2019-10-10-211121 exists...
Downloading archive to tmp directory...
Unzipping archive, this may take a while...
EXCEPTION: Compression::Strategy::ExtractFailed
/var/www/discourse/lib/compression/gzip.rb:49:in `block in extract_file'
/var/www/discourse/lib/compression/gzip.rb:45:in `open'
/var/www/discourse/lib/compression/gzip.rb:45:in `extract_file'
もちろん、そのサイトは GCP 上の直接データベースバックアップで十分だと思われますが、以前サムが自身の開発サイトで PG 11 を実行しており、PG 11 に関する問題があれば知りたいと述べていたことを覚えています。
@pfaffman 隠し設定である decompressed_file_max_size_mb のサイト設定を増やしてください。現在のデフォルト値は 1GB に設定されています。
デフォルト値を 100GB に引き上げるための PR は準備済みですが、まだマージされていません:
「いいね！」 7
@Roman さん、ありがとうございます。これでその問題は解決しましたね。
ただ、今度は invalid command \N のエラーが大量に発生しています（前の内容を確認する前にバッファが埋まってしまいました）。もしかすると、以下の情報が必要かもしれません。
ERROR: syntax error at or near "Shiny"
LINE 1: Shiny contest submission 2019-01-07 20:00:05.570573 2019-01-...
^
EXCEPTION: psql failed
/var/www/discourse/lib/backup_restore/restorer.rb:324:in `restore_dump'
/var/www/discourse/lib/backup_restore/restorer.rb:75:in `run'
はい、それは PG11 が原因だと思います。
「いいね！」 2
もし pg11 インスタンスならその通りですね！でも、これは標準的な 2 コンテナ構成のインストールです。
待ってください！バージョンが不一致しています。
root@community:/var/discourse# ./launcher enter data root@staging-data:/# psql --version
psql (PostgreSQL) 10.7 (Ubuntu 10.7-1.pgdg16.04+1)
復元先の環境は 10.9 です！これが原因でしょう。（pg11 も同様に失敗すると思いますが、その場合は同じインスタンスに復元しようとしています）。
明日、データコンテナをアップグレードして結果をお知らせします。お手伝いいただき、ありがとうございます。
「いいね！」 3
さて、両方を 10.10 にアップグレードしましたが（標準データテンプレートを使用）、依然として「無効なコマンド」のエラーが発生しました。
「無効なコマンド」エラーが発生し始めた際、リストアスクリプトを強制終了しました。その後、リストアを再試行すると（「無効なコマンド」メッセージの前に最初のエラーを取得しようとしたところ）、以下のエラーが発生しました：
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "theme_fields" does not exist
その後、両方のインスタンスで rake db:migrate を実行し、再度バックアップを取得したところ、リストアが成功しました。もしかすると、どこかでマイグレーションがスキップされたのでしょうか？
（上記の設定を変更した後、必要になる可能性のある方のために、それが不要になるまでのわずかな時間のために完全な手順を記載します）
./launcher enter app
rails c
SiteSetting.decompressed_file_max_size_mb=1000000
「いいね！」 1
また失敗しました。こちらは両方とも 2.4.0.beta6 です（1 つは 2c011252f1、もう 1 つはそれより少し新しい可能性があります）。
S3 から復元しています。アップロードあり・なしの両方で試しましたが、どちらも一見正常に動作しているように見えた後、以下のように失敗しました：
...
COPY 11871
COPY 3689
COPY 0
COPY 36550
COPY 0
COPY 14736
/usr/local/bin/discourse: line 2: 3232 Killed RAILS_ENV=production sudo -H -E -u discourse bundle exec script/discourse "$@"
これが表示されている唯一のメッセージですか？
S3 への依存関係を削除し、バックアップファイルをまずローカルにコピーしてみるのはどうでしょうか？
@pfaffman、このトピックで報告されている復旧に関する問題（2 つ、あるいは 3 つ）は、当初このトピックが対象としていたバグ（PG::UndefinedColumn: ERROR の問題）の発生事例ではないことを知っておくと良いでしょう。これらは明確に異なる問題ですので、それぞれ新しいトピックを立てることを検討してみてください。
「いいね！」 4