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オープンソースクラスターは、適切に構成および監視されている場合、年間99.99％以上のアップタイムを簡単に達成できることを確認できます。

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

Barmanとの私たちの使命は、次のような災害復旧の文化を促進することです。

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

  • 回復手順にさらに焦点を当てる

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

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

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

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

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

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

  • それは金曜日の夜になるでしょう、おそらくあなたがオフィスを出ようとしているときです。

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

  • ストレスになること間違いなしです。

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

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

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

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

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