バックアップがフォーラムをダウンさせ続ける

[piffy]

バックアップ作成がスペース不足でサイトをダウンさせるというサイクルを繰り返しています。

バックアップとアップロードを保存するために、別のDOボリュームを使用するように設定しました。ボリュームは300GBです。

私のバックアップ設定：

この問題は数ヶ月前から再発しています。管理者の受信トレイにバックアップ失敗のメッセージが表示されます（下記参照）。

ディスクの空き容量がありません

[2024-02-14 03:43:34] バックアップを最終処理中...
[2024-02-14 03:43:34] アーカイブを作成中: elite-fourum-2024-02-14-033845-v20240204204532.tar.gz
[2024-02-14 03:43:34] アーカイブが既に存在しないことを確認中...
[2024-02-14 03:43:34] 空のアーカイブを作成中...
[2024-02-14 03:43:34] データダンプをアーカイブ中...
[2024-02-14 03:43:58] アップロードをアーカイブ中...
[2024-02-14 03:55:03] 一時ファイル '/var/www/discourse/tmp/backups/default/2024-02-14-033845' ディレクトリを削除中...
[2024-02-14 03:55:03] アーカイブをgzip圧縮中、これには時間がかかる場合があります...
[2024-02-14 04:25:38] 例外: /var/www/discourse/lib/discourse.rb:138:in `exec': アーカイブのgzip圧縮に失敗しました。

gzip: /var/www/discourse/public/backups/default/elite-fourum-2024-02-14-033845-v20240204204532.tar.gz: ディスクの空き容量がありません

[2024-02-14 04:25:38] /var/www/discourse/lib/discourse.rb:172:in `execute_command'
/var/www/discourse/lib/discourse.rb:138:in `exec'
/var/www/discourse/lib/discourse.rb:34:in `execute_command'
/var/www/discourse/lib/backup_restore/backuper.rb:253:in `create_archive'
/var/www/discourse/lib/backup_restore/backuper.rb:40:in `run'
/var/www/discourse/lib/backup_restore.rb:13:in `backup!'
/var/www/discourse/app/jobs/regular/create_backup.rb:10:in `execute'
/var/www/discourse/app/jobs/base.rb:297:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-5.0.0/lib/rails_multisite/connection_management.rb:82:in `with_connection'
/var/www/discourse/app/jobs/base.rb:284:in `block in perform'
/var/www/discourse/app/jobs/base.rb:280:in `each'
/var/www/discourse/app/jobs/base.rb:280:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'
[2024-02-14 04:25:38] 古いバックアップを削除中...
[2024-02-14 04:25:38] クリーンアップ中...
[2024-02-14 04:25:38] '.tar' の残骸を削除中...
[2024-02-14 04:25:39] バックアップが完了したとマーク中...
[2024-02-14 04:25:39] バックアップ終了を 'system' に通知中...

その後、通知されない（と思われる）部分的に完了したバックアップが多数発生します。これらが蓄積して、新しいバックアップが毎日作成されようとしてサイトがダウンする状況になります。

これらは /admin/backups ページに表示されないため、手動でSSH接続して削除する必要があります。

この問題を再現するのは難しいことは承知していますが、何か明らかな間違いをしているのか、あるいは他の人も同様の問題に直面しているのか、疑問に思っています。

[Ed_S]

まず試すべきことは、圧縮されていないバックアップファイルではない部分を削除した後、最大バックアップ数を2に減らすことです。

いずれにしても、これらのバックアップをどこか別の場所（例えば自宅）に取得する方法を用意しておくのが最善だと思います。ホスティングサービスに問題が発生し、アカウントが削除された場合、何も残らなくなってしまいます。同様に、アカウントが侵害された場合や、火災が発生した場合も同様です。

オフサイトコピーを取得する方法（手動または自動）があれば、フラグメントをチェックして削除する方法に非常に近づきます。

以前にも提案しましたが、ダッシュボードは、バックアップファイルが作成されてから数日間読み取られていない場合に警告を出すべきです。これは比較的簡単なチェックであり、私の見解ではオフサイトコピーをチェックするための良い代理となります。

バックアップをブロックストレージに配置することも選択できます。これは別のプロバイダーを使用して行うことができます。そうすれば、インストールとバックアップの両方を失う可能性が低くなります。

バックアップと圧縮バックアップファイルの両方を短時間保持する必要がないようにするための、長らく保留されている作業があると思いますが、それを待つ価値はありません。それまでの間、保持しているN個のバックアップ、圧縮されていない形式で作成中のバックアップ用の1つ、そしてN個の中で最も古いものが削除される前に短時間必要な圧縮バックアップ用の1つ、合計N+2個のバックアップを保持するために必要なスペースが必要です。

N+2個のバックアップのためのディスクスペースが必要であり、バックアップが失敗した場合は、その部分を削除する必要があります。

[pfaffman (Jay Pfaffman)]

@piffy

/var/www/discourse/tmp/

そのディレクトリを300GBのパーティションにも配置する必要があることに注意してください。それがディスクをいっぱいにしている原因です。

アップロードをそのパーティションに移動することも検討できます。

[piffy]

それを手動で知っていますか？ yml設定など、変更する必要があるものはありますか？

再構築中にオフライン画面を静的に表示するように設定しているので、それが複雑になるかどうかはわかりません。

[pfaffman (Jay Pfaffman)]

以下のようなものですね。

volumes:
  - volume:
      host: /your/big/partition/tmp
      guest: /var/www/discourse/tmp

バックアップを大きなパーティションに保存するために、すでにそのようなことをしているのでしょう？

@piffy

再構築中にオフライン画面を静的に表示するように設定しているので、それが複雑になるかどうかはわかりません。

それはそうです。問題はおそらくそれではありませんが、Discourseが起動しているにもかかわらず、静的なオフラインページが表示され続けるという問題である場合は別です。

[piffy]

デジタルオーシャンのボリュームを拡張する際にコンソールでコマンドを実行する必要があることをこのトピックを作成した後で知りました。そのため、実質的に300GBすべてを使用していませんでした。

それを修正し、他に何も変更せずに、今日問題が再発しました。サイトがダウンしたとき、解凍されていないtarファイルが2つと、gzip圧縮されたファイルが3つありました。

次に、上記で議論された戦略を試します。

しかし、言いたかったのは、管理UIに失敗したバックアップがあることを示すインジケーターがあると良いということです。または、新しいバックアッププロセスをトリガーする際に*.tarファイルをすべてクリアするというのはどうでしょうか？この場合、管理UIからは見えない90GBの解凍されていないバックアップがありました。また、「バックアップ失敗」のDMもありませんでした。

[gerhard (Gerhard Schlager)]

ドロップレットのメモリ使用量はどうなっていますか？バックアッププロセスはクリーンアップルーチンを実行し、失敗した場合は管理者に通知を送信する必要があります。プロセスがメモリ不足 killer によって終了された場合、それは起こりません。

[pfaffman (Jay Pfaffman)]

@gerhard

メモリ不足でプロセスが終了した場合、それは起こりません。

それが起こっているのかもしれません！ディスクを使い果たす不完全なバックアップを残す「中断されたバックアップ」のシナリオをいくつかのサイトで目にしました。私の最も有力な説明は、バックアップの途中でOSが再起動することでしたが、OSの再起動がない場合でも見られました。

バックアッププロセスがメモリ不足で終了するということは、再現が十分に困難なため、これを説明できる可能性のある有力な説明のように思えます。

. . . .

ああ、しまった。この問題を抱えていたと記憶しているサイトの1つには16GBのRAMがありますが、それが説明になるとは思えません。そのサイトでは、毎週または毎月、S3にプッシュされた（またはプッシュされなかった）後にローカルディスクに残されたバックアップがあります。また、100GB以上の空きディスク容量があるため、ディスクがいっぱいになるほど問題が大きくなるまで数か月かかります。

削除したファイルのセットを次に示します。

forum-2024-03-11-123904-v20240202052058.tar.gz
forum-2024-03-09-123159-v20240202052058.tar.gz                           
forum-2024-03-07-123727-v20240202052058.tar.gz                           
forum-2024-03-05-123019-v20240202052058.tar.gz
forum-2024-03-03-123934-v20240202052058.tar.gz  

[Firepup650 (Firepup Sixfifty)]

それ、私も同感です。私が管理を手伝っているフォーラムでは、バックアップがS3にプッシュされずにサーバー上にランダムに残されており、それが原因でフォーラムが少なくとも一度ダウンしました。

[piffy]

これが役立つかどうかわかりませんが、DOからの指標を以下に示します。

7日間

24時間

拡大