CentOS7でBarmanを使用してPostgreSQLデータベースをバックアップ、復元、および移行する方法

提供:Dev Guides
移動先:案内検索

序章

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

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

  • ストレージやサーバー自体などの基盤となるインフラストラクチャコンポーネントの障害によるデータ損失からの保護
  • データの破損や不要または悪意のあるデータの損失からの保護
  • 本番データベースを開発環境またはテスト環境に移行する

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

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

PostgreSQLバックアップメソッドの簡単な紹介

Barmanのセットアップを開始する前に、PostgreSQLで使用可能なバックアップの種類とその使用法を確認してみましょう。 (バックアップ戦略のさらに広範な概要については、効果的なバックアップに関する記事をお読みください。)

PostgreSQLには、次の2種類のバックアップ方法があります。

  • 論理バックアップ
  • 物理バックアップ

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

  • 個々のデータベースまたはすべてのデータベースをバックアップします
  • スキーマのみ、データのみ、個々のテーブル、またはデータベース全体(スキーマとデータ)をバックアップします
  • 独自のバイナリ形式またはプレーンSQLスクリプトでバックアップファイルを作成します
  • PostgreSQLに同梱されているpg_restoreユーティリティを使用して復元できます
  • ポイントインタイムリカバリ(PITR)を提供しないでください

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

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

  • ポイントインタイムリカバリを提供する
  • PostgreSQLデータディレクトリおよびWAL(ログ先行書き込み)ファイルの内容をバックアップします
  • 大量のディスクスペースを取ります
  • PostgreSQLのpg_start_backupおよびpg_stop_backupコマンドを使用します。 ただし、これらのコマンドはスクリプト化する必要があるため、物理バックアップはより複雑なプロセスになります
  • 個々のデータベース、スキーマのみなどをバックアップしないでください。 それはオールオアナッシングアプローチです

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

バーマンバックアップのしくみ

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

BarmanまたはBackupand Recovery Manager は、プロのPostgresソリューション企業である2ndQuadrantの無料のオープンソースPostgreSQLバックアップツールです。 BarmanはPythonで記述されており、PostgreSQLインスタンスの物理的なバックアップと復元のシンプルで直感的な方法を提供します。 バーマンを使用するいくつかの利点は次のとおりです。

  • 完全無料です
  • これは手入れの行き届いたアプリケーションであり、ベンダーから専門的なサポートを受けられます
  • DBA / Sysadminを、複雑なスクリプトやcronジョブの作成とテストから解放します。
  • 複数のPostgreSQLインスタンスを1つの中央の場所にバックアップできます
  • 同じPostgreSQLインスタンスまたは別のインスタンスに復元できます
  • ネットワークトラフィックとディスクスペースを最小限に抑える圧縮メカニズムを提供します

目標

このチュートリアルでは、3つのDigitalOceanドロップレットを作成し、これらの2台のマシンにPostgreSQL 9.4をインストールし、3台目にBarmanをインストールします。

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

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

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

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

前提条件

このチュートリアルに従うには、それぞれが少なくとも 2GBのRAMと2つのCPUコアを備えた3つのDigitalOceanドロップレット(または独自のLinuxサーバー)を作成する必要があります。 ドロップレットの作成の詳細については説明しません。 詳細については、こちらをご覧ください。

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

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

  • main-db-server (IPアドレスを main-db-server-ip と表記します)
  • widget-db-server (IPアドレスを widget-db-server-ip と表記します)
  • barman-backup-server (IPアドレスを barman-backup-server-ip と表記します)

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

また、各サーバーにsudoユーザーを設定し、それを一般的なアクセスに使用する必要があります。 ほとんどのコマンドは2つの異なるユーザー(postgresbarman)として実行されますが、これらのアカウントに切り替えるには、各サーバーにもsudoユーザーが必要です。 sudo特権がどのように機能するかを理解するには、sudoアクセスの有効化に関するこのDigitalOceanチュートリアルを参照してください。

注:このチュートリアルでは、デフォルトのBarmanインストールディレクトリをバックアップ場所として使用します。 CentOSでは、この場所は/var/lib/barman/です。 2ndQuadrantは、デフォルトのパスを維持することをお勧めします。 実際のユースケースでは、データベースのサイズとバックアップされるインスタンスの数に応じて、このディレクトリをホストしているファイルシステムに十分なスペースがあることを確認する必要があります。


警告: このチュートリアルのコマンド、クエリ、または構成を運用サーバーで実行しないでください。. This tutorial will involve changing configurations and restarting PostgreSQL instances. Doing so in a live environment without proper planning and authorization would mean an outage for your application.


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

まず、 main-db-serverstandby-db-serverにPostgreSQL9.4をインストールして、データベース環境をセットアップします。

このLEPPスタックチュートリアルからPostgreSQLのインストール手順を完了してください。 このチュートリアルから、次のことを行う必要があります。

  • ステップ1—PostgreSQLのインストールのセクションに従ってください
  • ステップ2—PostgreSQLの構成のセクションに従ってください

ステップ2— PostgreSQL の構成で、pg_hba.confファイルに変更を加えてWebサーバーのデータベースにアクセスできるようにする代わりに、この行を追加して、Barmanサーバーが[ X203X] barman-backup-server IPアドレス、続いて/32

host  all     all     barman-backup-server-ip/32     trust

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

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

注: PostgreSQLをインストールすると、データベースサーバー上にpostgresというオペレーティングシステムユーザーが作成されます。 このアカウントにはパスワードがありません。 sudoユーザーから切り替えます。


main-db-serverstandby-db-serverの両方にPostgreSQLをインストールし、barmanから両方へのアクセスを許可していることを確認してください-バックアップサーバー

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

ステップ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

注: Barmanをインストールすると、barmanというオペレーティングシステムユーザーが作成されます。 このアカウントにはパスワードがありません。 sudoユーザーアカウントからこのユーザーに切り替えることができます。


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

ステップ4—サーバー間のSSH接続の構成

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

同様に、widget-db-serverbarman-backup-serverの間でSSHキーを確立します。その逆も同様です。

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

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

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

SSHがどのように機能するかについては詳しく説明しません。 参照できるSSHの基本事項に関するDigitalOceanに関する非常に優れた記事があります。

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

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

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

sudo su - postgres

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

ssh-keygen -t rsa

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

ENTERを2回押して、パスフレーズなしで秘密鍵を作成します。

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

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

注:残念ながら、ここではssh-copy-id barman@barman-backup-server-ipコマンドを使用できません。 これは、このコマンドが barman ユーザーのパスワードを要求するためです。これは、デフォルトでは設定されていません。 したがって、公開鍵の内容を手動でコピーする必要があります。


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

cat ~/.ssh/id_rsa.pub

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

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

sudo su - barman

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

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

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

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

ここで、接続をテストするには、 main-db-server に戻り、そこから接続をテストします。

ssh barman@barman-backup-server-ip

リモートサーバーの信頼性が不明であるという最初の警告が表示され、プロンプトを受け入れた後、main-db-serverサーバーからbarman-backup-server[への接続を確立する必要があります。 X222X]。 成功した場合は、exitコマンドを実行してセッションからログアウトします。

exit

SSHキー接続をさらに3回設定する必要があります。.sshディレクトリがすでに作成されている場合は、作成をスキップできます(これは必須ではありません)。

  • 今度はstandby-db-serverからbarman-backup-serverまで同じコマンドを再度実行します。
  • 3回目に実行します。今回は、barman-backup-serverbarmanユーザーから発信し、postgresユーザーに移動します。 main-db-server
  • 最後に、コマンドを実行して、barman-backup-serverbarmanユーザーからstandby-dbのpostgresユーザーにキーをコピーします。 -サーバー

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

standby-db-server から:

ssh barman@barman-backup-server-ip

barman-backup-server から:

ssh postgres@main-db-server-ip

barman-backup-server から:

ssh postgres@standby-db-server-ip

注: 3つのサーバーすべての間でSSH接続を確保することは、バックアップが機能するための要件です。


ステップ5—バックアップ用のBarmanの構成

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

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

行の先頭にあるセミコロン(;)は、その行がコメント化されていることを意味します。 ほとんどのLinuxベースのアプリケーションと同様に、Barmanのコメント化された構成パラメーターは、コメントを外して別の値を入力しない限り、システムがデフォルト値を使用することを意味します。

そのようなパラメータの1つがconfiguration_files_directoryで、デフォルト値は/etc/barman.dです。 つまり、有効にすると、Barmanはそのディレクトリ内の.confファイルをさまざまなPostgresサーバーのバックアップ構成に使用します。 メインファイルが長くなりすぎている場合は、バックアップするサーバーごとに個別のファイルを作成してください。

このチュートリアルを簡単にするために、すべてをデフォルトの構成ファイルに入れます。


sudoユーザーとして/etc/barman.confをテキストエディターで開きます(ユーザー barman は読み取りアクセス権しか持っていません):

sudo vi /etc/barman.conf

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

  • compressionの行のコメントを解除し、デフォルト値のgzip.を維持します。これは、PostgreSQLWALファイルがバックアップディレクトリにコピーされたときに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 postgres@main-db-server-ip
conninfo = host=main-db-server-ip user=postgres
retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF 7 days
wal_retention_policy = main

retention_policy設定は、Barmanが7日間のリカバリウィンドウに十分なバックアップを保持しながら、古い完全バックアップファイルと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 postgres@main-db-server-ip
conninfo = host=main-db-server-ip 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@barman-backup-server-ip:/var/lib/barman/main-db-server/incoming/%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 barman@barman-backup-server-ip:/var/lib/barman/main-db-server/incoming/%f'                # command to use to archive a logfile segment

sudoユーザーに戻ります。

PostgreSQLを再起動します。

sudo systemctl restart postgresql-9.4.service

注:既存の本番PostgreSQLインスタンスを構成している場合、これら3つのパラメーターがすでに設定されている可能性があります。 次に、archive_commandパラメータのみを追加/変更して、PostgreSQLがそのWALファイルをバックアップサーバーに送信するようにする必要があります。


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

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

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

barman check main-db-server

手順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の準備ができたので、手動でバックアップを作成しましょう。

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

barman backup main-db-server

この場合も、main-db-serverの値は、手順5で/etc/barman.confファイルにサーバーブロックの先頭として入力した値です。

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

出力

Starting backup for server main-db-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 main-db-server
        Older than first backup. Trashing file 000000010000000000000001 from server main-db-server
        000000010000000000000002
        000000010000000000000002.00000028.backup

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

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

ls -l /var/lib/barman

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

  • base:これはベースバックアップファイルが保存される場所です
  • incoming:PostgreSQLは、アーカイブのために、完成したWALファイルをこのディレクトリに送信します
  • wals:Barmanはincomingディレクトリの内容をwalsディレクトリにコピーします

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

バックアップの一覧表示

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

barman list-backup main-db-server
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が作成するバックアップを一意に識別するために使用されます。 この場合は20151111T051954です。 次の手順のためにバックアップIDが必要になります
  • 3番目の情報は、バックアップがいつ作成されたかを示します
  • 4番目の部分は、基本バックアップのサイズ(この場合は26.9 MB)です。
  • 文字列の5番目の最後の部分は、バックアップされたWALアーカイブのサイズを示します。

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

barman show-backup main-db-server backup-id

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

OutputBackup 20151111T051954:
  Server Name            : main-db-server
  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 main-db-server backup-id

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

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

理想的には、バックアップはスケジュールに従って自動的に実行される必要があります。

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

crontab -e

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

cron

30 23 * * * /usr/bin/barman backup main-db-server
* * * * * /usr/bin/barman cron

最初のコマンドは、毎晩午後11時30分にmain-db-serverの完全バックアップを実行します。 (/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だけが残っていることがわかります。

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

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

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

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

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

sudo systemctl stop postgresql-9.4.service

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

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

barman show-backup main-db-server latest

出力

Backup 20160114T173552:
  Server Name            : main-db-server
  Status                 : DONE
  PostgreSQL Version     : 90405
  PGDATA directory       : /var/lib/pgsql/9.4/data

  Base backup information:

. . .

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

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

また、Begin timeフィールド(上記の2016-01-14 17:35:53.164222-05:00)から、バックアップがいつ作成されたかを確認してください。

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

barman recover --target-time "Begin time"  --remote-ssh-command "ssh postgres@standby-db-server-ip"   main-db-server   backup-id   /var/lib/pgsql/9.4/data

ここにはかなりの数のオプション、引数、変数があるので、それらについて説明しましょう。

  • --target-time "Begin time"show-backupコマンドからの開始時刻を使用します
  • --remote-ssh-command "ssh postgres@standby-db-server-ip"widget-db-serverのIPアドレスを使用します
  • main-db-server/etc/barman.confファイルのデータベースサーバーの名前を使用します
  • backup-idshow-backupコマンドのバックアップIDを使用するか、必要に応じてlatestを使用します
  • /var/lib/pgsql/9.4/data:バックアップを復元するパス。 このパスは、スタンバイサーバー上のPostgresの新しいデータディレクトリになります。 ここでは、CentOSのPostgresのデフォルトのデータディレクトリを選択しました。 実際のユースケースでは、適切なパスを選択してください

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

バーマンリカバリーからの出力

Starting remote restore for server  main-db-server using backup backup-id
Destination directory: /var/lib/pgsql/9.4/data
Doing PITR. Recovery target time: Begin 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!

ここで、widget-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つのテーブルが表示されます。 つまり、ドロップされたテーブルを回復したばかりです。

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

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

結論

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

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

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

  • いくつのPostgreSQLインスタンスがバックアップされますか?
  • 指定された保存期間のすべてのバックアップをホストするのに十分なディスク容量がBarmanサーバーにありますか? サーバーのスペース使用量をどのように監視できますか?
  • 異なるサーバーのすべてのバックアップを同時に開始する必要がありますか、それともオフピーク期間全体でずらすことができますか? すべてのサーバーのバックアップを同時に開始すると、Barmanサーバーとネットワークに不要な負担がかかる可能性があります
  • BarmanサーバーとPostgresサーバー間のネットワーク速度は信頼できますか?

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

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