/var/discourse/shared/standalone/backups/default にバックアップが溜まり続けていますが、Amazon S3 にアップロードされています。
Discourse のセットアップは以下の通りです。
Discourse のバックアップ:
S3 バケット内のバックアップ:
そして /var/discourse/shared/standalone/backups/default の内容:
これは長期間続いており、これらの残ったファイルを削除するために毎月カレンダーにリマインダーを設定しています。バックアップログは空で、「まだログはありません…」となっており、エラーログにも Amazon S3 に関する問題は何も示されていません。
Discourse は定期的に更新されており、現在は 2.9.0.beta14 です。
gerhard
(Gerhard Schlager)
2
これは標準的なインストールですよね? OS(または他の何か)がアップロード中にバックアッププロセスを停止させている可能性はありますか? バックアップが失敗した場合でも、ローカルファイルはプロセスの最後に削除されるはずです。
「いいね!」 1
はい、DigitalOceanのドロップレット、Ubuntu 16.04.7 LTSに標準インストールしました。関連するログはどこにありますか?
pfaffman
(Jay Pfaffman)
4
しばらくの間、S3互換のサービスを使用していましたが、バックアップがローカルドライブに残ることが時々ありましたが、断続的でした。
/var/discourse/shared/standalone/logs/rails/production.log を確認してください。コマンドラインバックアップを実行して、その動作があるかどうかを確認するだけです。
「いいね!」 3
本番環境のログは1週間しか遡れないため、古い「削除されていない」バックアップはその範囲外になりますが、今後のバックアップには注意しておきます。バックアップエラーのエントリは、11/30のログにこれだけありました。
Started GET "/.env.backup" for 3.236.147.46 at 2022-11-29 19:15:57 +0000
ActionController::RoutingError (No route matches [GET] "/.env.backup")
/var/discourse/shared/standalone/backups/default に新しい削除されていないバックアップが表示されますが、production.log には何も表示されません。production_errors.log にも何も表示されません。他にどこを見ればよいでしょうか?
追伸 CLI からバックアップを実行したところ、バックアップは正常に削除されました。エラーが発生するかどうか、さらに数回試してみます。
「いいね!」 1
CLI経由で削除されていないローカルバックアップを再現することに成功していませんが、ナイトリーバックアップ中に週に1〜2回発生し続けています。また、production.logにバックアップログの出力が表示されません。それが書き込まれている場所は本当にそこですか、@pfaffman?
pfaffman
(Jay Pfaffman)
8
そうだと思います。some other S3 service で同様の問題が発生したとき、Discourse やそのサービスのエラーを見つけることができませんでした。そして諦めて別のものに切り替えました。しかし、あなたは AWS、S3、本物を使っているので、とても驚いています。
このように試しました。
grep -r "Output file is stored on S3" /var/discourse
このフレーズはCLIバックアップ出力の最後の行なので、何も見つかりません。
gerhard
(Gerhard Schlager)
10
ホストOSの自動アップデートによりサーバーが再起動する可能性はありますか? S3へのアップロード中に発生する可能性があります。OSのログに何か記録されていますか? backup_time_of_dayサイト設定をデフォルト値または別の時刻にリセットして、問題が消えるかどうかを確認してみてください。
「いいね!」 1
いいえ、現在の稼働時間は36日です。DigitalOceanのドロップレットバックアップが同時に実行されていることが原因ではないかと疑っていましたが、それは週に一度しか発生せず、私の未削除バックアップはそれよりも頻繁に発生します。
別の backup_time_of_day を試してみます。UTC 2:00に設定されていたので、デフォルトのUTC 3:30が違いをもたらすかどうか見てみましょう。
「いいね!」 2
pfaffman
(Jay Pfaffman)
12
おおお!それは良い質問ですね。それなら説明がつきます。きっとそれでしょう。そして、バックアップと再起動の両方にとって、深夜は良い時間です。私が別のサービスに変更したときに問題が解消された理由を完全に説明するには至りませんが、運が良かったか、変更したものがより高速だったのかもしれません。
ああ。残念。
16日後、これが解決策だったようです。これ以上削除されていないバックアップはありません。何が競合を引き起こしていたのかはわかりませんが、今は問題ありません。
「いいね!」 2
system
(system)
クローズされました:
14
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.