前書き

  • PostgreSQL *は、メンテナンスの容易さ、費用対効果、および他のオープンソーステクノロジーとの簡単な統合により、Webおよびモバイルアプリケーション開発者に非常に人気のあるオープンソースデータベースプラットフォームです。

PostgreSQL環境を維持する重要なタスクの1つは、データベースを定期的にバックアップすることです。 バックアップは、あらゆる組織の災害復旧(DR)プロセスの一部を形成します。 これはいくつかの理由で重要です。

  • ストレージやサーバー自体などの基盤となるインフラストラクチャコンポーネントの障害によるデータ損失に対する保護

  • データの破損およびデータの望ましくないまたは悪意のある損失に対する保護

  • 本番データベースを開発環境またはテスト環境に移行する

通常、データベースのバックアップと復元の責任はDBAの肩にかかっています。 ただし、小規模な組織や新興企業では、システム管理者、DevOpsエンジニア、またはプログラマーが独自のデータベースバックエンドを作成する必要があります。 そのため、PostgreSQLを使用するすべての人にとって、バックアップの仕組みとバックアップからの復元方法を理解することが重要です。

このチュートリアルでは、Barmanバックアップサーバーをセットアップし、プライマリデータベースサーバーからバックアップを作成し、スタンバイサーバーに復元します。

PostgreSQLバックアップ方法の簡単な紹介

Barmanのセットアップを開始する前に、PostgreSQLで使用可能なバックアップの種類とその使用方法を少し見てみましょう。 (バックアップ戦略のより広範な概要については、https://www.digitalocean.com/community/tutorials/how-to-choose-an-effective-backup-strategy-for-your-vps [効果的なバックアップに関する記事をお読みください]。)

PostgreSQLは、2種類のバックアップ方法を提供します。

  • 論理バックアップ

  • 物理的なバックアップ

論理バックアップは、データベースのスナップショットのようなものです。 これらは、PostgreSQLに同梱されている `+ pg_dump `または ` pg_dumpall +`ユーティリティを使用して作成されます。 論理バックアップ:

  • 個々のデータベースまたはすべてのデータベースをバックアップします

  • スキーマのみ、データのみ、個々のテーブル、またはデータベース全体(スキーマとデータ)をバックアップします

  • 独自のバイナリ形式またはプレーンSQLスクリプトでバックアップファイルを作成する

  • PostgreSQLに同梱されている `+ pg_restore +`ユーティリティを使用して復元できます

  • *ポイントインタイムリカバリ(PITR)*を提供しない

つまり、午前2時にデータベースの論理バックアップを作成し、そこから復元すると、復元されたデータベースは午前2時になります。 特定の時点、たとえば午前1時30分に復元を停止する方法はありません。 午前10時にバックアップを復元すると、8時間分のデータが失われます。

物理バックアップは、バイナリ形式のみを処理し、ファイルレベルのバックアップを作成するため、論理バックアップとは異なります。 物理バックアップ:

  • ポイントインタイムリカバリを提供する

  • PostgreSQLの_dataディレクトリ_および_WAL_(Write Ahead Log)ファイルの内容をバックアップします

  • より多くのディスク容量を確保する

  • PostgreSQLの `+ pg_start_backup `および ` pg_stop_backup +`コマンドを使用します。 ただし、これらのコマンドはスクリプト化する必要があるため、物理バックアップはより複雑なプロセスになります

  • 個々のデータベース、スキーマのみなどをバックアップしないでください。 それはオールオアナッシングのアプローチです

WALファイルには、データベースで発生する_transactions_(INSERT、UPDATEまたはDELETE)のリストが含まれています。 データを含む実際のデータベースファイルは、データディレクトリ内にあります。 したがって、物理バックアップから特定の時点に復元する場合、PostgreSQLは最初にデータディレクトリの内容を復元し、次にWALファイルからその上でトランザクションを再生します。 これにより、データベースが時間内に一貫した状態になります。

  • Barmanバックアップの仕組み*

従来、PostgreSQL DBAは独自のバックアップスクリプトとスケジュールされた `+ cron +`ジョブを作成して物理バックアップを実装していました。 バーマンはこれを標準化された方法で行います。

  • Barman または Backup and Recovery Manager *は、http://www.pgbarman.org/ [2ndQuadrant]の無料のオープンソースPostgreSQLバックアップツールです。これは、プロのPostgresソリューション企業です。 BarmanはPythonで書かれており、PostgreSQLインスタンスの物理的なバックアップと復元のシンプルで直感的な方法を提供します。 バーマンを使用する利点は次のとおりです。

  • 完全に無料です

  • よく管理されたアプリケーションであり、ベンダーから専門的なサポートを受けられます

  • DBA / Sysadminが複雑なスクリプトと `+ cron +`ジョブを作成およびテストする必要がなくなります

  • 複数のPostgreSQLインスタンスを1つの中央の場所にバックアップできます

  • 同じPostgreSQLインスタンスまたは異なるインスタンスに復元できます

  • ネットワークトラフィックとディスクスペースを最小化する圧縮メカニズムを提供します

目標

このチュートリアルでは、3つのDigitalOcean Dropletsを作成し、これらのマシンのうち2つにPostgreSQL 9.4をインストールし、3つ目にBarmanをインストールします。

PostgreSQLサーバーの1つがメインデータベースサーバーになります。ここで、運用データベースを作成します。 2番目のPostgreSQLインスタンスは空であり、バックアップから復元できるスタンバイマシンとして扱われます。

Barmanサーバーはメインデータベースサーバーと通信し、物理バックアップとWALアーカイブを実行します。

次に、ライブデータベースからテーブルを削除して、「災害」をエミュレートします。

最後に、バックアップされたPostgreSQLインスタンスをBarmanサーバーからスタンバイサーバーに復元します。

前提条件

このチュートリアルを実行するには、3つ以上のDigitalOcean Droplets(または独自のLinuxサーバー)を作成し、それぞれに少なくとも* 2 GBのRAM *と2つのCPUコアを作成する必要があります。 ドロップレットの作成の詳細については説明しません。詳細についてはhttps://www.digitalocean.com/community/tutorials/how-to-create-your-first-digitalocean-droplet-virtual-server [こちら]をご覧ください。

3つのサーバーすべてに同じOS(* CentOS 7 * x64ビット)が必要です。

次のようにマシンに名前を付けます。

  • * main-db-server *(IPアドレスをとして示します)

  • * standby-db-server *(IPアドレスをとして指定します)

  • * barman-backup-server *(IPアドレスをとして示します)

マシンの実際のIPアドレスは、DigitalOceanコントロールパネルから確認できます。

また、各サーバーにsudoユーザーを設定し、一般的なアクセスに使用する必要があります。 ほとんどのコマンドは2人の異なるユーザー(* postgres および barman *)として実行されますが、これらのアカウントに切り替えるには各サーバーにもsudoユーザーが必要です。 sudo特権の仕組みを理解するには、https://www.digitalocean.com/community/tutorials/how-to-edit-the-sudoers-file-on-ubuntu-and-centos [sudoアクセスの有効化に関するDigitalOceanチュートリアル]を参照してください。 。

ステップ1-PostgreSQLデータベースサーバーのインストール

まず、PostgreSQL 9.4を* main-db-server および standby-db-server *にインストールして、データベース環境をセットアップします。

https://www.digitalocean.com/community/tutorials/how-to-set-up-a-two-node-lepp-stack-on-centos-7 [このLEPPスタックチュートリアル]からPostgreSQLのインストール手順を完了してください。 このチュートリアルでは、次のことを行う必要があります。

  • セクション「ステップ1-PostgreSQLのインストール」に従ってください

  • セクション*ステップ2-PostgreSQLの設定*に従ってください

ステップ2-PostgreSQLの設定*で、Webサーバーのデータベースへのアクセスを許可するために + pg_hba.conf +`ファイルを変更する代わりに、この行を追加して、Barmanサーバーが barman-backup- server * IPアドレスとそれに続く `+ / 32 +

host    all     all     /32        trust

これにより、Barmanサーバーからの接続を受け入れるようにPostgreSQLが構成されます。

そのセクションの残りの指示は、そのまま従うことができます。

  • main-db-server standby-db-server の両方にPostgreSQLをインストールし、 barman-backup-server *から両方にアクセスできることを確認してください。

次に、メインデータベースサーバーにサンプルデータを追加します。

ステップ2-PostgreSQLデータベースとテーブルの作成

両方のマシンにPostgreSQLをインストールして構成したら、サンプルデータを* main-db-server *に追加して、運用環境をシミュレートします。

  • main-db-server で、ユーザー postgres *に切り替えます。

sudo su - postgres

`+ psql +`ユーティリティを起動して、データベースサーバーにアクセスします。

psql

`+ psql +`プロンプトから、次のコマンドを実行してデータベースを作成し、切り替えます:

CREATE DATABASE mytestdb;
\connect mytestdb;

出力メッセージは、ユーザー `+ postgres `としてデータベース ` mytestdb +`に接続されたことを通知します。

次に、データベースに2つのテーブルを追加します。

CREATE TABLE mytesttable1 (id integer NULL);
CREATE TABLE mytesttable2 (id integer NULL);

これらには、「+ mytesttable1 」および「 mytesttable2 +」という名前が付けられています。

「+ \ q 」と入力して「 ENTER」を押して、クライアントツールを終了します。

ステップ3-Barmanのインストール

次に、バックアップを制御および保存するBarmanをバックアップサーバーにインストールします。

  • barman-backup-server *でこの手順を完了します。

これを行うには、まず次のリポジトリをインストールする必要があります。

  • Enterprise Linux(EPEL)リポジトリ用の追加パッケージ

  • PostgreSQLグローバル開発グループRPMリポジトリ

次のコマンドを実行してEPELをインストールします。

sudo yum -y install epel-release

以下のコマンドを実行して、PostgreSQLリポジトリをインストールします。

sudo wget http://yum.postgresql.org/9.4/redhat/rhel-7Server-x86_64/pgdg-centos94-9.4-1.noarch.rpm
sudo rpm -ivh pgdg-centos94-9.4-1.noarch.rpm

最後に、このコマンドを実行してBarmanをインストールします。

sudo yum -y install barman

バーマンがインストールされています! 次に、サーバーが相互に安全に接続できることを確認しましょう。

手順4-サーバー間のSSH接続の構成

このセクションでは、* main-db-server barman-backup-server *の間のパスワードなしの安全な接続のためのSSHキーを確立します。

同様に、* standby-db-server barman-backup-server *の間でSSHキーを確立し、その逆も同様です。

これは、PostgreSQL(両方のデータベースサーバー上)とBarmanがバックアップおよび復元中に互いに「通信」できるようにするためです。

このチュートリアルでは、次のことを確認する必要があります。

  • ユーザー* postgres は、 main-db-server から barman-backup-server *にリモート接続できます。

  • ユーザー* postgres は、 standby-db-server から barman-backup-server *にリモートで接続できます。

  • ユーザー* barman は、 barman-backup-server から main-db-server *にリモート接続できます。

  • ユーザー* barman は、 barman-backup-server から standby-db-server *にリモート接続できます。

SSHの仕組みについては詳しく説明しません。 参照できるSSHの基本事項についてhttps://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys[DigitalOceanに関する非常に良い記事]があります。

ただし、必要なコマンドはすべてここに含まれています。

ユーザー* postgres main-db-server から barman-backup-server *に接続するための接続を設定するために、これを1回行う方法を示します。

  • main-db-server から、ユーザー postgres *に切り替えます(まだ現在のユーザーでない場合)。

sudo su - postgres

次のコマンドを実行して、SSHキーペアを生成します。

ssh-keygen -t rsa

`+ ENTER`を押して、キーファイルのデフォルトの場所と名前を受け入れます。

パスフレーズなしで秘密キーを作成するには、「+ ENTER」を2回押します。

キーが生成されると、* postgres *ユーザーのホームディレクトリの下に、キーが含まれる `+ .ssh +`ディレクトリが作成されます。

  • barman-backup-server 上の barman *ユーザーの + .ssh`ディレクトリの下にある + authorized_keys`ファイルにSSH公開鍵をコピーする必要があります。

次のコマンドを実行して、* postgres *ユーザーの公開キーの内容を出力します。

cat ~/.ssh/id_rsa.pub

出力の内容をコピーします。

  • barman-backup-server サーバーに接続されているコンソールに切り替えて、ユーザー barman *に切り替えます。

sudo su - barman

次のコマンドを実行して、 `+ .ssh `ディレクトリを作成し、その権限を設定し、公開キーの内容を ` authorized_keys +`ファイルにコピーし、最後にそのファイルを読み取り可能および書き込み可能にします。

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

`+`ではなく、 ` ssh-rsa +`で始まる長い公開キー文字列を引用符で囲んでください。

キーをリモートサーバーにコピーしました。

次に、接続をテストするために、* main-db-server *に切り替えて、そこから接続をテストします。

リモートサーバーの信頼性に関する最初の警告が不明であり、プロンプトを受け入れると、* main-db-server サーバーから barman-backup-server *への接続が確立されます。 成功したら、 `+ exit +`コマンドを実行してセッションからログアウトします。

exit
  • SSHキー接続をさらに3回セットアップする必要があります。*すでに作成されている場合は、 `+ .ssh +`ディレクトリの作成をスキップできます(ただし、これは必要ではありません)。

  • 今度は* standby-db-server から barman-backup-server *に同じコマンドを再度実行します

  • 3回目に実行します。今回は* barman-backup-server barman ユーザーから発信され、 main-db-server postgres *ユーザーに移動します。

  • 最後に、コマンドを実行して、* barman-backup-server barman ユーザーから standby-db-server postgres *ユーザーにキーをコピーします。

新しい接続に関する最初の警告を受け入れることができるように、必ず各方法で接続をテストしてください。

  • standby-db-server *から:

  • barman-backup-server *から:

  • barman-backup-server *から:

手順5-バックアップ用のBarmanの構成

次に、メインのPostgreSQLサーバーをバックアップするようにBarmanを構成します。

BARMANのメイン設定ファイルは `+ / etc / barman.conf +`です。 このファイルには、グローバルパラメーターのセクションと、バックアップするサーバーごとに個別のセクションが含まれています。 デフォルトファイルには、* main *というサンプルPostgreSQLサーバーのセクションが含まれていますが、コメントアウトされています。 これをガイドとして使用して、バックアップする他のサーバーをセットアップできます。

  • sudoユーザー*としてテキストエディターで `+ / etc / barman.conf +`を開きます(ユーザー* barman *は読み取り専用です)。

sudo vi /etc/barman.conf

グローバルパラメータは、 `+ [barman] +`セクションで定義されます。 このセクションで、次の変更を行います。 完成した値は、箇条書きの下に表示されます。

  • `+ compression `の行のコメントを解除し、デフォルト値の ` gzip。+`を保持します。これは、PostgreSQL WALファイルが-バックアップディレクトリの下にコピーされると、gzip圧縮形式で保存されることを意味します。

  • `+ reuse_backup `の行のコメントを外し、デフォルト値の ` link +`を保持します。 PostgreSQLサーバーのフルバックアップを作成する場合、Barmanはファイルレベルの増分バックアップを作成して、バックアップディレクトリのスペースを節約しようとします。 これは、rsyncおよびハードリンクを使用します。 増分完全バックアップの作成には、データ重複排除方法と同じ利点があります。時間とディスクスペースの節約です。

  • `+ immediate_checkpoint `の行のコメントを外し、その値を ` true `に設定します。 このパラメーター設定は、Barmanが完全バックアップを開始するときに、PostgreSQLに ` CHECKPOINT +`の実行を要求することを保証します。 チェックポイントにより、PostgreSQLのメモリキャッシュ内の変更されたデータがデータファイルに書き込まれます。 バックアップの観点からは、BARMANが最新のデータ変更をバックアップできるため、これにより価値が追加されます。

  • 「+ basebackup_retry_times 」の行のコメントを解除し、「 3+」の値を設定します。 完全バックアップを作成するときに、コピー操作が何らかの理由で失敗した場合、BarmanはPostgreSQLサーバーへの接続を3回試行します

  • `+ basebackup_retry_sleep `の行のコメントを外し、デフォルト値の ` 30 +`のままにします。 各再試行の間に30秒の遅延があります

  • `+ last_backup_maximum_age +`の行のコメントを解除し、その値を `+1 DAYS +`に設定します

新しい設定は次のようになります。

/etc/barman.confからの抜粋

[barman]
barman_home = /var/lib/barman

. . .

barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
reuse_backup = link

. . .

immediate_checkpoint = true

. . .

basebackup_retry_times = 3
basebackup_retry_sleep = 30
last_backup_maximum_age = 1 DAYS

ここで行っているのはこれです:

  • デフォルトのバックアップ場所を維持する

  • バックアップスペースを保存するように指定します。 WALログは圧縮され、ベースバックアップは増分データコピーを使用します

  • 何らかの理由で完全バックアップが途中で失敗した場合、Barmanは3回再試行します

  • PostgreSQLサーバーの最後の完全バックアップの経過日数は1日を超えてはなりません。

ファイルの最後に、新しいセクションを追加します。 そのヘッダーには、角括弧内に「+ [main-db-server] +」と表示されます。 (Barmanでより多くのデータベースサーバーをバックアップする場合は、サーバーごとにこのようなブロックを作成し、それぞれに一意のヘッダー名を使用できます。)

このセクションには、データベースサーバーの接続情報と、いくつかの一意のバックアップ設定が含まれます。

これらのパラメーターを新しいブロックに追加します。

/etc/barman.confからの抜粋

[main-db-server]
description = "Main DB Server"
ssh_command = ssh [email protected]
conninfo = host= user=postgres
retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF  days
wal_retention_policy = main

`+ retention_policy +`設定は、7日間のリカバリウィンドウに十分なバックアップを保持しながら、Barmanが古いフルバックアップファイルとWALログを自動的に上書きすることを意味します。 つまり、データベースサーバー全体を過去7日間の任意の時点に復元できるということです。 実稼働システムの場合、おそらくこの値を高く設定して、古いバックアップを手元に置いてください。

`+ ssh_command `および ` conninfo +`パラメーターで* main-db-server *のIPアドレスを使用する必要があります。 それ以外の場合は、上記の設定を正確にコピーできます。

変更されたファイルの最終バージョンは、すべてのコメントと変更されていない設定を除いた次のようになります。

/etc/barman.confからの抜粋

[barman]
barman_home = /var/lib/barman

. . .

barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
reuse_backup = link

. . .

immediate_checkpoint = true

. . .

basebackup_retry_times = 3
basebackup_retry_sleep = 30
last_backup_maximum_age = 1 DAYS

. . .

[main-db-server]
description = "Main DB Server"
ssh_command = ssh [email protected]
conninfo = host= user=postgres
retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF 7 days
wal_retention_policy = main

ファイルを保存して閉じます。

次に、* main-db-server *がバックアップを作成するように設定されていることを確認します。

ステップ6-postgresql.confファイルの構成

バックアップ(またはアーカイブ)モードをオンにするために、* main-db-server *で行う最後の構成が1つあります。

まず、* barman-backup-server から着信バックアップディレクトリの値を見つける必要があります。 Barmanサーバーで、ユーザー barman *に切り替えます。

sudo su - barman

次のコマンドを実行して、受信バックアップディレクトリを見つけます。

barman show-server main-db-server | grep incoming_wals_directory

これにより、次のような出力が得られます。

barman show-server command outputincoming_wals_directory: /var/lib/barman/main-db-server/incoming

`+ incoming_wals_directory `の値を書き留めます。この例では、「 / var / lib / barman / main-db-server / incoming +」です。

  • main-db-server *コンソールに切り替えます。

現在のユーザーでない場合は、ユーザー* postgres *に切り替えます。

テキストエディタで `+ postgresql.conf`ファイルを開きます:

vi $PGDATA/postgresql.conf

ファイルに次の変更を加えます。

  • `+ wal_level `パラメーターのコメントを外し、その値を ` minimal `ではなく ` archive +`に設定します

  • `+ archive_mode `パラメータのコメントを外し、その値を ` off `ではなく ` on +`に設定します

  • + archive_command +`パラメータのコメントを外し、その値を `+ '' +ではなく + ‘rsync -a%p barman @:/%f’ + `に設定します。 BarmanサーバーのIPアドレスを使用します。 `+ incoming_wals_directory +`の値が異なる場合は、代わりにその値を使用してください

postgresql.confからの抜粋

wal_level = archive                     # minimal, archive, hot_standby, or logical

. . .

archive_mode = on               # allows archiving to be done

. . .

archive_command = 'rsync -a %p [email protected]:/%f'                # command to use to archive a logfile segment
  • sudoユーザー*に戻ります。

PostgreSQLを再起動します。

sudo systemctl restart postgresql-9.4.service

ステップ7-バーマンのテスト

ここで、Barmanがすべての設定を正しく設定し、* main-db-server *に接続できるかどうかを確認します。

  • barman-backup-server で、現在のユーザーでない場合はユーザー barman *に切り替えます。 次のコマンドを実行して、メインデータベースサーバーへの接続をテストします。

barman check

手順5で `+ / etc / barman.conf +`ファイルのサーバーブロックの角括弧の間に別の名前を入力した場合は、代わりにその名前を使用する必要があります。

すべてが正常であれば、出力は次のようになります。

barman check command outputServer main-db-server:
       PostgreSQL: OK
       archive_mode: OK
       wal_level: OK
       archive_command: OK
       continuous archiving: OK
       directories: OK
       retention policy settings: OK
       backup maximum age: FAILED (interval provided: 1 day, latest backup age: No available backups)
       compression settings: OK
       minimum redundancy requirements: OK (have 0 backups, expected at least 0)
       ssh: OK (PostgreSQL server)
       not in recovery: OK

バックアップの最大経過時間「+ FAILED」状態について心配する必要はありません。 これは、最新のバックアップが1日以上経過しないようにBarmanを構成したために発生しています。 バックアップはまだ作成されていないため、チェックは失敗します。

他のパラメーターのいずれかが「+ FAILED」状態にある場合は、先に進む前にさらに調査して問題を修正する必要があります。

チェックが失敗する理由は複数あります。たとえば、BarmanがPostgresインスタンスにログインできない、PostgresがWALアーカイブ用に設定されていない、SSHがサーバー間で機能しないなどです。 原因が何であれ、バックアップを行う前に修正​​する必要があります。 前の手順を実行し、すべての接続が機能することを確認します。

Barmanで設定されたPostgreSQLサーバーのリストを取得するには、次のコマンドを実行します。

barman list-server

現時点では次のように表示されるはずです。

出力

main-db-server - Main DB Server

ステップ8-最初のバックアップの作成

バーマンの準備ができたので、手動でバックアップを作成しましょう。

  • barman-backup-server barman *ユーザーとして次のコマンドを実行して、最初のバックアップを作成します。

barman backup

繰り返しますが、「+」の値は、ステップ5で「 / etc / barman.conf +」ファイルにサーバーブロックのヘッドとして入力したものです。

これにより、PostgreSQLデータディレクトリの完全バックアップが開始されます。 インスタンスには2つのテーブルを持つ小さなデータベースが1つしかないため、非常に迅速に終了するはずです。

出力

Starting backup for server  in /var/lib/barman/main-db-server/base/20151111T051954
Backup start at xlog location: 0/2000028 (000000010000000000000002, 00000028)
Copying files.
Copy done.
Asking PostgreSQL server to finalize the backup.
Backup size: 26.9 MiB. Actual size on disk: 26.9 MiB (-0.00% deduplication ratio).
Backup end at xlog location: 0/20000B8 (000000010000000000000002, 000000B8)
Backup completed
Processing xlog segments for
       Older than first backup. Trashing file 000000010000000000000001 from server
       000000010000000000000002
       000000010000000000000002.00000028.backup

バックアップファイルの場所

では、バックアップはどこに保存されますか? 答えを見つけるには、 `+ / var / lib / barman +`ディレクトリの内容をリストします:

ls -l /var/lib/barman

そこに1つのディレクトリがあります: + main-db-server +。 これは、Barmanが現在バックアップするように構成されているサーバーであり、そのバックアップはそこにあります。 (他のサーバーをバックアップするようにBarmanを設定すると、サーバーごとに1つのディレクトリが作成されます。) `+ main-db-server +`ディレクトリの下に、3つのサブディレクトリがあります。

  • + base +:これはベースバックアップファイルが保存される場所です

  • + incoming +:PostgreSQLはアーカイブのために完成したWALファイルをこのディレクトリに送信します

  • + wals +:Barmanは `+ incoming `ディレクトリの内容を ` wals +`ディレクトリにコピーします

復元中、Barmanは `+ base`ディレクトリからターゲットサーバーのデータディレクトリにコンテンツを復元します。 その後、 `+ wals +`ディレクトリのファイルを使用してトランザクションの変更を適用し、ターゲットサーバーを一貫した状態にします。

バックアップのリスト

サーバーのすべてのバックアップを一覧表示する特定のBarmanコマンドがあります。 そのコマンドは `+ barman list-backup `です。 次のコマンドを実行して、 `+`に対して返されるものを確認します。

barman list-backup
Outputmain-db-server 20151111T051954 - Wed Nov 11 05:19:46 2015 - Size: 26.9 MiB - WAL Size: 0 B
  • 出力の最初の部分はサーバーの名前です。 この場合、 + main-db-server +

  • 2番目の部分(長い英数字の値)は、バックアップのバックアップIDです。 バックアップIDは、Barmanが作成したバックアップを一意に識別するために使用されます。 この場合、それは「++」です。 次のステップのためにバックアップIDが必要になります

  • 3番目の情報は、バックアップがいつ作成されたかを示します

  • 4番目の部分は、基本バックアップのサイズです(この場合は26.9 MB)

  • 文字列の5番目と最後の部分は、バックアップされたWALアーカイブのサイズを示します

バックアップの詳細を表示するには、サーバーの名前と、前のコマンドのバックアップID(この例では「++」)を使用してこのコマンドを実行します。

barman show-backup

詳細な情報セットが表示されます。

OutputBackup :
 Server Name            :
 Status                 : DONE
 PostgreSQL Version     : 90405
 PGDATA directory       : /var/lib/pgsql/9.4/data

 Base backup information:
   Disk usage           : 26.9 MiB (26.9 MiB with WALs)
   Incremental size     : 26.9 MiB (-0.00%)
   Timeline             : 1
   Begin WAL            : 000000010000000000000002
   End WAL              : 000000010000000000000002
   WAL number           : 1
   WAL compression ratio: 99.84%
   Begin time           : 2015-11-11 05:19:44.438072-05:00
   End time             : 2015-11-11 05:19:46.839589-05:00
   Begin Offset         : 40
   End Offset           : 184
   Begin XLOG           : 0/2000028
   End XLOG             : 0/20000B8

 WAL information:
   No of files          : 0
   Disk usage           : 0 B
   Last available       : 000000010000000000000002

 Catalog information:
   Retention Policy     : VALID
   Previous Backup      : - (this is the oldest base backup)
   Next Backup          : - (this is the latest base backup)

さらにドリルダウンして、どのファイルがバックアップに入るかを確認するには、次のコマンドを実行します。

barman list-files

これにより、特定のバックアップから復元するために必要なベースバックアップとWALログファイルのリストが表示されます。

ステップ9-バックアップのスケジュール

理想的には、バックアップはスケジュールに従って自動的に行われます。

この手順では、バックアップを自動化します。また、保持ポリシーより古いファイルが削除されるように、バックアップのメンテナンスを実行するようBarmanに指示します。 スケジューリングを有効にするには、* barman-backup-server barman *ユーザーとしてこのコマンドを実行します(必要に応じてこのユーザーに切り替えます)。

crontab -e

これにより、ユーザー* barman *の `+ crontab +`ファイルが開きます。 ファイルを編集し、これらの行を追加して、保存して終了します。

cron

30 23 * * * /usr/bin/barman backup
* * * * * /usr/bin/barman cron

最初のコマンドは、* main-db-server *の完全バックアップを毎晩午後11:30に実行します。 ( `+ / etc / barman.conf +`ファイルでサーバーに別の名前を使用した場合は、代わりにその名前を使用してください。)

2番目のコマンドは毎分実行され、WALファイルとベースバックアップファイルの両方でメンテナンス操作を実行します。

ステップ10-「災害」のシミュレーション

作成したばかりのバックアップから復元する方法が表示されます。 復元をテストするには、まずデータを失った「災害」シナリオをシミュレートしましょう。

ここにテーブルをドロップしています。 実稼働データベースではこれを行わないでください!

  • main-db-server コンソールに戻り、まだユーザーでない場合は、ユーザー postgres *に切り替えます。

`+ psql +`ユーティリティを起動します:

psql

`+ psql `プロンプトから、次のコマンドを実行してデータベースコンテキストを ` mytestdb +`に切り替えます。

\connect mytestdb;

次に、データベース内のテーブルをリストします。

\dt

出力には、このチュートリアルの最初に作成したテーブルが表示されます。

Output            List of relations
Schema |     Name     | Type  |  Owner
--------+--------------+-------+----------
public | mytesttable1 | table | postgres
public | mytesttable2 | table | postgres

次に、次のコマンドを実行して、テーブルの1つを削除します。

drop table mytesttable2;

ここで `+ \ dt +`コマンドを再度実行すると:

\dt

`+ mytesttable1 +`のみが残っていることがわかります。

これは、バックアップから復元するデータ損失状況のタイプです。 この場合、バックアップを別のサーバー(* standby-db-server *)に復元します。

手順11-リモートサーバーへの復元または移行

このセクションに従って、バックアップを復元するか、最新のPostgreSQLバックアップを新しいサーバーに移行できます。

  • standby-db-server *に移動します。

最初に、sudoユーザーとしてPostgreSQLサービスを停止します。 (サービスの実行中に復元を実行しようとすると、再起動が停止します。)

sudo systemctl stop postgresql-9.4.service

サービスが停止したら、* barman-backup-server に移動します。 現在のユーザーでない場合は、ユーザー barman *に切り替えます。

最新のバックアップの詳細を見つけましょう。

barman show-backup  latest

出力

Backup :
 Server Name            :
 Status                 : DONE
 PostgreSQL Version     : 90405
 PGDATA directory       : /var/lib/pgsql/9.4/data

 Base backup information:

. . .

   Begin time           :
   End time             : 2016-01-14 17:35:55.054673-05:00

出力から、最初の行に印刷されたバックアップIDを書き留めます(上記の「+」)。 ` latest `バックアップに必要なデータがある場合、 ` latest +`をバックアップIDとして使用できます。

また、 + Begin time +`フィールド(上記の `++)から、バックアップが作成された時期を確認します。

次に、このコマンドを実行して、指定されたバックアップを* barman-backup-server から standby-db-server *に復元します。

barman recover --target-time ""  --remote-ssh-command "ssh [email protected]"         /var/lib/pgsql/9.4/data

ここには非常に多くのオプション、引数、変数がありますので、それらを説明しましょう。

  • -target-time" ": `+ show-backup +`コマンドの開始時間を使用する

  • -remote-ssh-command" ssh postgres @ ":* standby-db-server *のIPアドレスを使用する

  • ++: `+ / etc / barman.conf +`ファイルのデータベースサーバーの名前を使用します

  • ++: `+ show-backup `コマンドのバックアップIDを使用します。または、必要な場合は ` latest +`を使用します

  • + / var / lib / pgsql / 9.4 / data +:バックアップを復元するパス。 このパスは、スタンバイサーバー上のPostgresの新しいデータディレクトリになります。 ここでは、CentOSでPostgresのデフォルトのデータディレクトリを選択しました。 実際のユースケースでは、適切なパスを選択してください

復元操作を成功させるには、次のような出力を受け取る必要があります。

Barman Recoveryからの出力

Starting remote restore for server   using backup
Destination directory: /var/lib/pgsql/9.4/data
Doing PITR. Recovery target time:
Copying the base backup.
Copying required WAL segments.
Generating recovery.conf
Identify dangerous settings in destination directory.

IMPORTANT
These settings have been modified to prevent data losses

postgresql.conf line 207: archive_command = false

Your PostgreSQL server has been successfully prepared for recovery!

ここで、もう一度* standby-db-server *コンソールに切り替えます。 * sudoユーザー*として、PostgreSQLサービスを開始します。

sudo systemctl start postgresql-9.4.service

それはそれでなければなりません!

データベースが稼働していることを確認しましょう。 ユーザー* postgres *に切り替えて、 `+ psql +`ユーティリティを起動します。

sudo su - postgres
psql

データベースコンテキストを `+ mytestdb +`に切り替えて、その中のテーブルを一覧表示します。

\connect mytestdb;
\dt

出力

           List of relations
Schema |     Name     | Type  |  Owner
--------+--------------+-------+----------
public | mytesttable1 | table | postgres
public | mytesttable2 | table | postgres
(2 rows)

リストには、データベース内の2つのテーブルが表示されます。 つまり、ドロップされたテーブルを回復したばかりです。

大規模な回復戦略に応じて、* standby-db-server にフェールオーバーするか、復元されたデータベースが機能していることを確認してから、このセクションを再度実行して mainに復元することができます。 -db-server *。

他のサーバーに復元するには、PostgreSQLをインストールし、Barmanサーバーに適切に接続していることを確認してから、ターゲットリカバリサーバーのIPアドレスを使用してこのセクションに従います。

結論

このチュートリアルでは、PostgreSQLサーバーをバックアップするためにBarmanをインストールおよび構成する方法を見てきました。 また、これらのバックアップから復元または移行する方法も学びました。

慎重に検討すれば、BarmanはすべてのPostgresQLデータベースの中央リポジトリになることができます。 堅牢なバックアップメカニズムとシンプルなコマンドセットを提供します。 ただし、バックアップの作成は話の半分にすぎません。 バックアップは常に別の場所に復元して検証する必要があります。 この演習は定期的に行う必要があります。

Barmanをバックアップ戦略に適合させるためのいくつかの質問:

  • いくつのPostgreSQLインスタンスがバックアップされますか?

  • 指定された保持期間のすべてのバックアップをホストするのに十分なディスク容量がBarmanサーバーにありますか? サーバーのスペース使用量を監視するにはどうすればよいですか?

  • 異なるサーバーのすべてのバックアップを同時に開始する必要がありますか、それともオフピーク期間中にずらすことができますか? すべてのサーバーのバックアップを同時に開始すると、Barmanサーバーとネットワークに不必要な負担がかかる可能性があります

  • BarmanサーバーとPostgresサーバー間のネットワーク速度は信頼できますか?

留意すべきもう1つの点は、Barmanが個々のデータベースをバックアップおよび復元できないことです。 ファイルシステムレベルで動作し、オールオアナッシングアプローチを使用します。 バックアップ中に、すべてのデータファイルを含むインスタンス全体がバックアップされます。復元すると、これらのファイルはすべて復元されます。 同様に、Barmanではスキーマのみまたはデータのみのバックアップを実行できません。

したがって、 `+ pg_dump `または ` pg_dumpall `を使用した論理バックアップとBarmanを使用した物理バックアップの両方を使用するように、バックアップ戦略を設計することをお勧めします。 そうすれば、個々のデータベースを迅速に復元する必要がある場合、 ` pg_dump +`バックアップを使用できます。 ポイントインタイムリカバリには、Barmanバックアップを使用します。