Introduction

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

  • データ破損

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

  • ヒューマンエラー

  • 自然災害

このような場合、ICTマネージャまたはDBAは、インシデントを修正し、できるだけ短時間でデータベースを回復できる必要があります。通常、この分野を「災害リカバリ**」と呼び、より広くは「ビジネス継続性」と呼びます。

ビジネスの継続性の中で、Wikipediaで定義されている2つの基本的な指標に精通することが重要です。

  • **Recovery Point Objective (RPO)** ：「メジャーインシデントのためにITサービスからデータが失われる可能性のある最大対象期間」

  • **Recovery Time Objective (RTO)** ：「ビジネス継続性の中断に関連する容認できない結果を回避オーダーに、災害（または中断）後にビジネスプロセスを復元する必要がある目標期間とサービスレベル」

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

当然、私たちは皆、 RPO=0 （* “ゼロデータロス” ）およびRTO=0（ゼロダウンタイム*、ユートピア）を望んでいます-それが私たちの祖母のレシピウェブサイトであっても。実際には、慎重なコスト分析フェーズにより、ビジネス継続性の要件を決定できます。

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

EnterpriseDBでの経験に基づいて、 Barmanおよびrepmgrを使用したPostgreSQLオープンソースクラスターは、適切に構成および監視されていれば、1年間で99.99％以上の稼働率を容易に達成できることを確認できます。

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

Barmanの私たちの使命は、災害リカバリの文化をプロモートすることです。

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

  • リカバリ手順にさらに焦点を当てる

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

  • バックアップのテスト（テスト済みのバックアップのみが有効であると見なすことができます）を手動または自動（バーマンのフックスクリプトで創造的に！）で促進します。

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

  • 3〜6か月ごとにチームと定期的にスケジュールされた訓練と災害リカバリシミュレーションを要請する PostgreSQLとBarmanの継続的なモニタリングに依存しており、異常を迅速に特定できます。

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

  • 金曜日の夕方になります。おそらく、オフィスを出ようとしています。

  • 休暇中（世界中のクルーズの真ん中）になり、他の誰かがそれに対処しなければならないときです。

  • それは確かにストレスになるだろう。

  • 使用可能な最後のバックアップが有効であることを確信できなかったことを後悔します。

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

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

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

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