Introduction

完璧な世界では、バックアップは必要ありません。ただし、特にビジネス環境では、「不測の事態」が発生した場合に備えておくことが重要です。データベースのシナリオでは、予期せぬことが次のいずれかの形で発生する可能性があります。

  • データ破損

  • システム障害（ハードウェア障害を含む）

  • ヒューマンエラー

  • 自然災害

このような場合、ICTマネージャーまたはDBAは、可能な限り短時間でインシデントを修正し、データベースを復旧できるはずです。通常、この規律を ディザスターリカバリー 、より広義にはビジネス継続性と呼びます。

ビジネス継続性では、ウィキペディアで定義されている2つの基本的なメトリックを理解することが重要です。

：「重大なインシデントによりITサービスからデータが失われる可能性のある最大対象期間」

：「ビジネス継続性の中断に関連する容認できない結果を回避するために、災害（または混乱）後にビジネスプロセスを復元する必要があるターゲット期間とサービスレベル」

簡単に言うと、RPOは損失しても許容されるデータの最大量を表し、RTOはサービスに許容できる最大ダウンタイムを表します。

当然のことながら、私たちは皆、 RPO=0 （「データ損失ゼロ」）と RTO=0 （ダウンタイムゼロ、ユートピア）を望んでいます-たとえそれが祖母のレシピWebサイトであっても。実際には、慎重なコスト分析フェーズにより、ビジネス継続性の要件を判断できます。

幸いなことに、 Barman と PostgreSQL で構成されるオープンソーススタックでは、同期ストリーミングレプリケーションのおかげでRPO=0を達成できます。 RTOは、 **repmgr** のような高可用性ソリューションの焦点です。したがって、 Barmanとrepmgrを統合することにより、RTOをほぼゼロに劇的に削減できます。

EnterpriseDBでの経験に基づいて、 Barmanとrepmgrを使用したPostgreSQLオープンソースクラスターは、適切に構成して監視した場合、1年で99.99％を超えるアップタイムを簡単に達成できることを確認できます。

いずれにせよ、実際のツールよりも、災害復旧に関連する文化的側面を強調することが重要です。人なくして道具は役に立たない。

Barmanの使命は、次のようなディザスターリカバリーの文化を促進することです。

  • バックアップ手順に焦点を当てる

  • 回復手順にさらに焦点を当てています

  • チームメンバーのためのPostgreSQLのクラッシュリカバリ、バックアップ、ポイントインタイムリカバリ、およびレプリケーションの強力な理論的および実践的な概念に関する教育とトレーニングに依存しています

  • 手動または自動でバックアップのテストを促進します（テストされたバックアップのみが有効と見なされます）（Barmanのフックスクリプトで創造的にしてください！）

  • Devopsチームのすべてのメンバー（はい、システム管理者やDBAだけでなく、開発者）による回復手順の定期的な実践を促進します

  • 3〜6か月ごとにチームと定期的にスケジュールされた訓練と災害復旧シミュレーションを要請します

  • PostgreSQLとBarmanの継続的な監視に依存しており、異常を迅速に特定できます

さらに、災害が発生したとき（はい、いつ）に備えて、自分とチームにできることをすべて行います。

  • それは金曜日の夜になるでしょう。ほとんどの場合、ちょうどオフィスを出ようとします。

  • あなたが休暇中（世界一周クルーズの真っ最中）で、他の誰かが対処しなければならないとき。

  • 確かにストレスになります。

  • 利用可能な最後のバックアップが有効かどうかを確認できないことを後悔するでしょう。

  • 回復するのにおよそどれくらい時間がかかるか分からない限り、毎秒は永遠のように思えます。

怖がらないで、準備してください。

2011年、これらの目標を念頭に置いて、 2ndQuadrant は、現在PostgreSQLの最も使用されているバックアップツールの1つであるBarmanの開発を開始しました。 Barmanは「Backup and Recovery Manager」の頭字語です。

現在、 BarmanはLinuxおよびUnixオペレーティングシステムでのみ動作します。