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

投稿日: 2019-11-08 2022-10-21
タグ: Backups, CentOS, postgresql

序章

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

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

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

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

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

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

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

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

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

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

個々のデータベースまたはすべてのデータベースをバックアップします
スキーマのみ、データのみ、個々のテーブル、またはデータベース全体（スキーマとデータ）をバックアップします
独自のバイナリ形式またはプレーンSQLスクリプトでバックアップファイルを作成します
を使用して復元できます pg_restore PostgreSQLにも同梱されているユーティリティ
ポイントインタイムリカバリ（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つの異なるユーザー（postgresとbarman）として実行されますが、これらのアカウントに切り替えるには、各サーバーにもsudoユーザーが必要です。 sudo特権がどのように機能するかを理解するには、sudoアクセスの有効化に関するこのDigitalOceanチュートリアルを参照してください。

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

警告： 本番サーバーでは、このチュートリアルのコマンド、クエリ、または構成を実行しないでください。このチュートリアルでは、構成を変更し、PostgreSQLインスタンスを再起動します。適切な計画と承認なしにライブ環境でこれを行うと、アプリケーションが停止することになります。

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

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

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

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

ステップ2— PostgreSQL を構成する代わりに、 pg_hba.conf Webサーバーのデータベースへのアクセスを許可するファイルの場合、 barman-backup-server IPアドレスを使用して、Barmanサーバーが接続できるようにこの行を追加し、その後に /32:

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

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

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

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

main-db-serverとstandby-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;

出力メッセージは、データベースに接続していることを通知します mytestdb ユーザーとして postgres.

次に、データベースに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-serverとbarman-backup-serverの間およびその逆の安全なパスワードなしの接続のためのSSHキーを確立します。

同様に、widget-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の基本事項に関するDigitalOceanに関する非常に優れた記事があります。

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

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

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

sudo su - postgres

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

ssh-keygen -t rsa

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

プレス ENTER パスフレーズなしで秘密鍵を作成するために2回。

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

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

注：残念ながら、 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

で始まる長い公開鍵文字列を必ず入力してください ssh-rsa 引用符の間ではなく public_key_string.

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

ここで、接続をテストするには、 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-serverのbarmanユーザーから発信し、のpostgresユーザーに移動します。 main-db-server
最後に、コマンドを実行して、barman-backup-serverのbarmanユーザーから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サーバーのバックアップ構成用のそのディレクトリ内のファイル。メインファイルが長くなりすぎている場合は、バックアップするサーバーごとに個別のファイルを作成してください。

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

開ける /etc/barman.conf テキストエディタでsudoユーザーとして（ユーザー 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 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

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

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

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

/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 パラメータを設定し、その値をに設定します archive それ以外の minimal
コメントを外す archive_mode パラメータを設定し、その値をに設定します on それ以外の off
コメントを外す 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

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

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

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-serverでbarmanユーザーとして次のコマンドを実行し、最初のバックアップを作成します。

barman backup main-db-server

繰り返しますが、 main-db-server 値は、サーバーブロックのヘッドとして入力したものです。 /etc/barman.conf 手順5のファイル。

これにより、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

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

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

復元中に、バーマンはコンテンツを復元します 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

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

Output
Backup 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-serverでbarmanユーザーとしてこのコマンドを実行します（必要に応じてこのユーザーに切り替えます）。

crontab -e

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

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 バックアップには必要なデータがあり、使用できます latest バックアップIDとして。

また、バックアップがいつ行われたかを確認します。 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-id：からのバックアップIDを使用します show-backup コマンド、または使用 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バックアップを使用します。

getdocs

13036