CentOS7でBarmanを使用してPostgreSQLデータベースをバックアップ、復元、および移行する方法
序章
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つの異なるユーザー(postgresとbarman)として実行されますが、これらのアカウントに切り替えるには、各サーバーにも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-serverとstandby-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-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;
出力メッセージは、ユーザー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-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回押して、パスフレーズなしで秘密鍵を作成します。
キーが生成されると、 postgresユーザーのホームディレクトリの下に.ssh
ディレクトリが作成され、その中にキーが含まれます。
次に、SSH公開鍵をbarman-backup-serverのbarmanユーザーの.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-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サーバーのバックアップ構成に使用します。 メインファイルが長くなりすぎている場合は、バックアップするサーバーごとに個別のファイルを作成してください。
このチュートリアルを簡単にするために、すべてをデフォルトの構成ファイルに入れます。
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-serverでbarmanユーザーとして次のコマンドを実行し、最初のバックアップを作成します。
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-serverでbarmanユーザーとしてこのコマンドを実行します(必要に応じてこのユーザーに切り替えます)。
crontab -e
これにより、ユーザーbarmanのcrontab
ファイルが開きます。 ファイルを編集し、これらの行を追加してから、保存して終了します。
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-id
:show-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バックアップを使用します。