はじめに#

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

データの破損
システム障害ハードウェア障害を含む
人的エラー
自然災害

このような場合、ICTマネージャーまたはDBAは、可能な限り最短の時間でインシデントを修正し、データベースを復旧できる必要があります。私たちは通常、この分野を ディザスターリカバリー 、より広範には ビジネス継続性 と呼んでいます。

ビジネス継続性の範囲では、Wikipediaで定義されている2つの基本的なメトリックをよく理解することが重要です。

[ Recovery Point Objective(RPO) ][rpo] “重大なインシデントによりITサービスからデータが失われる可能性のある最大目標期間”
[ Recovery Time Objective (RTO) ][rto] 「災害または中断後に、関連する受け入れがたい結果を回避するためにビジネスプロセスを復元する必要がある目標期間とサービスレベル」事業継続の中断とともに”

一言で言えば、RPOは損失してもよいデータの最大量を表し、RTOはサービスに許容できる最大ダウンタイムを表します。

当然のことながら、私たち全員が RPO=0 「ゼロデータ損失」と RTO=0 ゼロダウンタイム*、理想郷を望んでいます。たとえそれが祖母のレシピウェブサイトであったとしても。実際には、注意深いコスト分析フェーズにより、ビジネス継続性の要件を決定できます。

幸いなことに、 Barman と PostgreSQL で構成されるオープンソーススタックを使用すると、同期ストリーミングレプリケーションのおかげでRPO=0を達成できます。 RTOは、[ repmgr ][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オペレーティングシステムでのみ動作します。