バックアップと復旧計画

サイトが公開されるにあたり、適切なバックアップ戦略を確保したいと考えています。以下の手順を導入しました。他に不足している点はありますか?

データベースバックアップ

  • Discourse は 1 日に 1 回データベースのバックアップを行います。
  • 追加で cron によるデータベースバックアップが毎日実行されます。(UI ベースのバックアップから 12 時間後)
  • バックアップは S3 バケット(別のデータセンター)に保存されます。

コアファイル

以下のファイルは、1 日 2 回 S3 バケット(別のデータセンター)にバックアップされます。

  • discourse/containers/app.yml
  • discourse/shared/standalone/uploads/
  • discourse/shared/standalone/backups/
  • discourse/shared/standalone/ssl/
  • discourse/shared/standalone/letsencrypt/

ファイルのバックアップは、データベースバックアップの 30 分後に 1 日 2 回実行されます。

S3: アップロード

  • アップロードの毎日のバックアップは、別のデータセンターの S3 バケットに保存されます。

サーバーバックアップ

  • サーバー全体の週次バックアップ - 4 つの週次バックアップを保持します。
  • 毎年、1 つの週次バックアップをマスターバックアップとしてリモートロケーションに保存します。

これにより、サーバーをそのまま、または新しいサーバーに復元するために必要なすべてのデータと設定が提供されるはずです。

他に不足している点はありますか?

「いいね!」 1

それは推奨される方法です。データベースを1日に1回バックアップすると、そのフォーラムで発生した可能性のある最大24時間分のデータを失うリスクがあります。

少なくとも2回、問題ないと言われましたが、なぜ問題ないのか誰も説明してくれませんでした。そのため、私は6時間ごとにデータベースをバックアップしています。私のフォーラムはそれほど忙しくないので、そのリスクは取れます。比較のために言うと、私のeコマースは4分ごとにバックアップしています。

「いいね!」 1

データベースのバックアップ頻度を上げるにはどうすればよいですか? 1日2回が理想ですが、UIの機能では1日1回しか設定できません。

cronジョブ(コンテナ内ではなく、サーバー上で)を実行できます。

docker exec app bash -c "discourse backup"

データが本当に重要であれば、PostgreSQLレプリケーションサーバーをセットアップし、2番目のサーバーでコミットごとに実行するようにできます。

「いいね!」 1

これはcrontabの内容です。

docker exec app discourse backup --sql-only

これはDiscourse独自のバックアップCLIコマンドで、docker exec appはコンテナ外で実行される(appはコンテナ名です)と案内されました。

そして、通常のバックアップと同じバケットにジャンプするようにS3を設定したためです。

一つ小さな問題があります…すぐにバックアップが大量になります。sql-dumpを別に行い、aws-cliで移動してから、一定期間より古いものをすべて削除すべきかどうかわかりません。それともVPSで同じことをすべきでしょうか。

しかし、それがsql-dumpを取得する最も簡単な方法です。

「いいね!」 1

これは内部ディスコースバックアップルーチンをアクティブにし、すべての通知がそのまま残ると仮定します。

UI内でバックアップスケジューリングをオフにして、すべてcronで管理しますか?それとも、UI内で1つ実行し、追加はcronで行いますか?

いいえ、両方やります。システムも自分自身も、それほど信用していません。バックアップの量が問題になることはめったになく、不足が問題です。

「いいね!」 1

@Jagsterと@pfaffman、cron経由で追加のデータベースを設定するのを手伝ってくれてありがとう。これにより、最悪の場合でもデータ損失は12時間に短縮されます。

「いいね!」 2