newpage

＃はじめに

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

  • データ破損

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

  • ヒューマンエラー

  • 自然災害

このような場合、ICTマネージャまたはDBAは、インシデントを修正し、可能な限り短時間でデータベースを回復できる必要があります。通常、この分野を災害リカバリと呼び、もっと広い意味で事業継続性と呼びます。

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

  • [* Recovery Point Objective（RPO）*] [rpo]：「メジャーインシデントが原因でITサービスからデータが失われる可能性がある最大対象期間」

  • [目標復旧時間（RTO）] [rto]：_ “関連する容認できない結果を回避オーダーに、災害（または混乱）の後にビジネスプロセスを復元する必要がある目標期間とサービスレベル事業継続性が途切れる」_

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

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

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

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

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

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

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

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

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

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

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

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

  • PostgreSQLとバーマンの連続モニタリングに依存し、それは速やかに任意の異常を識別することができます

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

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

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

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

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

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

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

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

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