複数のバックアップスケジュール

返信はここか新規投稿か迷っています:機能リクエスト - 「添付ファイルを含める」と「添付ファイルを含めない」で別々のスケジュールを設定できるようにする。

毎日、あるいはデータベースが小さいので数回、短いバックアップができたら嬉しいです。添付ファイルは、はるかに数が少なく、通常はソースを再度見つけることができるため、1週間分失っても壊滅的なダメージはないでしょう。これにより、ストレージを圧倒することなく、安全性を高めることができます。
ソースは見ていませんが、リストアが別個のエンティティである必要があるか、少なくとも2つのソースで異なるリストアポイントを持つことができる必要があるため、かなりのオーバーホールになる可能性があります。

「いいね!」 4

このリクエストの推奨されるアクションは、通常、外部ツールを使用して他のデータベースバックアップを作成することです。

アップロードをS3に移動すると、データベースのみのバックアップを作成でき、アップロードを気にする必要がなくなります。

「いいね!」 6

かなりもっともだ。外部ツールを検討し始めると、組み込みの(ある程度)誤操作防止機能付きの管理コンソールよりも、通常はより大きな混乱を引き起こすことができる「外部からひどい状況を引き起こす方法」を思い浮かべてしまう。

前回、私や他の人が同じことを尋ねたとき、回答は以前と同じでした。

  • 1日1回のバックアップで十分
  • スクリプトやcronのような外部ツールを使用する

さて、データベースからの1日1回のバックアップでは不十分で、1時間ごとなら十分かもしれません。
外部ツールなら何でもできるというのは本当です。しかし、他のすべてのアプリはネイティブでまともなバックアップを提供していますが、Discourseはそうではありません。

その理由を知りたいです。

  • 「ただやりたくない、だから誰も必要としない」
  • 技術的に非常に困難または高価である

さて、常に3番目の選択肢があります:Marketplace

WordPress(人気のWebプラットフォーム)で多くのバックアップが必要な場合、有料のバックアッププラグインを使用する必要があります。そのため、他のすべてのアプリがネイティブでそれを提供しているわけではないかもしれません。少なくとも私はそうしていますが、その決定を下したのはずっと昔のことなので、悪い決定だったのかもしれません。

その理由は、多くのバックアップがあるとディスクがいっぱいになり、セルフホストサイトがダウンする最も一般的な理由の1つ(これは「高価」なカテゴリに入ると思います)になるからです。したがって、アイデアは、あなたが何十億ものバックアップを管理し、ディスクスペースを管理するのに十分なスキルを持っているなら、さまざまな方法でそれを解決できるということです。そして、毎時バックアップが必要な場合は、アップロードの数十または数百のコピーではなく、データベースのみのバックアップにする必要があります。

したがって、毎時バックアップは、S3にアップロードがあり、データベースのみのバックアップを実行してから、ローカルディスクを心配しないようにS3にプッシュできる場合にのみ意味があります。そして、それを望むセルフホストサイトはかなり少数です。

それらすべてが整っている場合、毎時のデータベースのみのバックアップを実行するプラグインは、1〜2時間の作業、またはプラグインの作成方法がわからず、毎時のジョブの作成方法を理解する必要がある場合は2〜10時間以上の作業にはならないでしょう。

「いいね!」 1

それは本当です。WordPress自体ではあまりできません。だからこそ、多くのプラグイン(良いものも悪いものも)が存在するのです。

それは真実ではありません。バックアップ自体ではなく、追加機能にのみ費用がかかります。

もちろん、ファイルやシステム自体を頻繁にバックアップする意味はありません。データベース自体は全く別の問題です。トラフィックが多い場合は、少なくとも15分ごとに実行する必要があります。

質問は非常に簡単です。失ってもよいコンテンツはどれくらいですか?

許容できる最大のデータ損失がこれほど少ないのであれば、バックアップを頻繁に取得する代わりに、Postgresレプリケーションソリューションの使用を検討することをお勧めします。

「いいね!」 4

他に知らないデータはありますか?それとも、システム、Docker/Discourse/など、アップロードされたものを含む、より広義の「データ」を使用していますか?

これらのファイルは、簡単に、またはわずかな費用で取得できます。ただし、アップロードされたもの以外は、それがS3がある理由です :wink:

いいえ、データベースのデータのことです。

「いいね!」 1

それなら、ほとんどが小さいですが、フォーラム自体を考えると最大です。しかし、何らかの理由で、私たちはこれに戻っています。

これは技術的な問題なのか、それとも精神的な問題なのか、ぜひお聞きしたいと思います。あるいは、これは実際にビジネスモデルの一部であり、バックアップが簡単で機能する場合、ホスティングは1つのピッチを失うのでしょうか?そして、そのようなセールスピッチがあるのかどうかさえわかりません。以前にも要求されたことがあるのに、なぜバックアップの改善がそれほど大きな問題なのか、理解しようとしているだけです。

これに関して、策略や悪意のある計画があると疑う必要はありません。より頻繁なバックアップにそれほど関心があるとは思えません。もしそうなら、誰かがプラグインを作成していたはずです。それは数時間の作業でしょう。Marketplace でそのリクエストが溢れているようには見えません。

要点は以下の通りだと思います。

  • 小規模なフォーラムでは、1日に新しいデータがあまりないため、失ってもそれほど多くなく、より頻繁なバックアップは労力に見合わないでしょう。
  • 大規模なフォーラムでは、より頻繁なバックアップはパフォーマンスとストレージを消費します。
  • 非常に大規模なフォーラムでは、別のソリューション(ホットスタンバイデータベースサーバーへのレプリケーションなど)を検討する必要があります。

バックアップが実際に必要になる可能性も非常に小さいことを忘れないでください。Communiteq の歴史(8年以上)の中で、バックアップを復元する必要があったのはわずか1回*だけで、それもファイルシステムの復旧に数時間待てなかったという、私たちの焦りが原因でした。

*) (クライアントの要求による復元、主に非本番フォーラムでの変更ロールバック、および毎月の復元テストを除く)

「いいね!」 4

もし私がここで検索しても、何らかの理由でDiscourseがクラッシュし、バックアップからの復元しか解決策がなかったというトピックは見つかりません。

しかし、Discourseが非常に堅牢で最新のバックアップを必要としないというのは良いことです。まあ、それは完全に真実ではないことはわかっています。

したがって、円が閉じられ、私が始めたところに戻りました。

そして3番目の選択肢。私がDiscourseのテストを事実上、ここで、そして自分でやっている限り、そのような基本的な機能にお金を払うつもりはありません。

さて、チームからのコメントなしに話しています。また:rofl:

開発にはいくらかかると思いますか?価格によっては、興味があれば今すぐ資金提供する用意があります。:dollar:

その問題はすでにCDCKによって対処されています。彼らが応答するのを少し待ってください、それだけです。

その通りです。日次バックアップではユースケースに十分でない場合は、個別の PostgreSQL サーバーで Discourse を実行する を参照して、独自の PostgreSQL インスタンスを実行し、必要に応じてバックアップと高可用性を処理してください。

「いいね!」 3

設定の柔軟性やフロントエンドに必要な作業量にもよりますが、250〜500ドルくらいだと思います。まだ実際にはどれくらいかかるか調べていませんが。@RGJ ならもっと安くやってくれるかもしれません。彼は驚くほど早く作業をこなすことがあります。

編集:ああ、このトピックは終了しています。もし興味があれば、私に連絡するか、Marketplace に投稿してください。