毎日のバックアップで十分ですか?

バックアップとレプリケーションは異なるものです。

バックアップは、ある時点でのデータのスナップショットを提供します。復元ポイントを提供します。

レプリケーションは、すべての操作を別のシステムに分散させることで、複数の場所にデータを持つようにするものです。削除もレプリケートされます。

真に耐障害性を高めたい場合は、両方が必要です。(さらに多くも…)

したがって、レプリケーションは現在のデータを複数の場所に持つという問題しか解決しません。バックアップは、システムを指定された時点に復元する方法を提供します。

Discourse はストレージに 2 つのメカニズムを使用します。

  1. 添付ファイルを除くすべてのものに対する PostgreSQL データベース
  2. 添付ファイルはローカルシステムまたは S3 に保存されます

PostgreSQL データベースに保存されているデータをバックアップおよび/またはレプリケートするには、PostgreSQL のドキュメントでその方法を確認できます。バックアップについて、およびレプリケーションを参照してください。

添付ファイルはもう少し厄介です。S3 に保存する場合は、S3 バックアップを使用できます。ローカルに保存されたファイルの場合は、さまざまなローカルシステムオプションを使用できます。

フルバックアップの作成は、データ量によっては重いタスクです。そのため、頻繁に実行するのは容易ではありません。Discourse の標準的なバックアップ手順は、フルバックアップを作成することです。データを失うリスクを本当に減らしたい場合は、他のオプションを探す必要があります。

1 つのオプションは、ホスティングサービスによって提供される可能性があります。ボリュームスナップショットです。これは、ボリュームに保存されているデータの「瞬時」コピーを作成する方法を提供します。これにより、その時点までボリュームを復元できます。ボリュームスナップショットは、使用されているファイルシステムに応じて OS 内でも利用できる場合があります。(たとえば、btrfs はこれをサポートしています。)

それに加えて、PostgreSQL のドキュメントでは、データベースのより継続的なバックアップを作成する方法についても説明されており、データベースの優れたポイントインタイムリカバリが可能になります。(バックアップをオフサイトに送信することを忘れないでください。)これはフルバックアップよりもはるかに高速です。

より粒度の高い添付ファイルのバックアップについては、フル+差分バックアップの管理を可能にするさまざまなバックアップツールを使用できます。たとえば、duplicity です。または、rsync(削除なし)を使用することもできます。スナップショットの間では、ファイルを失う可能性があります。削除なしで S3 を使用する方が安全です。ファイルはすでに別のシステム上にあるためです。

結論として、Discourse の標準的なバックアップメカニズムは、より頻繁なバックアップスケジュールには適していません。より多くのバックアップが必要な場合は、標準の PostgreSQL バックアップ/レプリケーション機能、S3、ボリュームスナップショットなどの組み合わせを使用してください。

私のサイトでは、定期的なバックアップに Discourse のバックアップシステムを使用していません。まだ毎日のバックアップはありますが、pg_dumps と duplicity の設定の組み合わせを使用しています(backupninja 経由で調整されています)。

「いいね!」 3