CentOS7でBarmanを使用して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サーバーから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
新しい設定は次のようになります。
[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を使用してより多くのデータベースサーバーをバックアップする場合は、サーバーごとにこのようなブロックを作成し、それぞれに一意のヘッダー名を使用できます。)
このセクションには、データベースサーバーの接続情報と、いくつかの固有のバックアップ設定が含まれています。
新しいブロックに次のパラメータを追加します。
[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
パラメーター。 それ以外の場合は、上記の設定を正確にコピーできます。
変更されたファイルの最終バージョンは、すべてのコメントと変更されていない設定を除いて、次のようになります。
[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
、代わりにそれを使用してください
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
詳細な情報セットが表示されます。
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
これにより、 crontab
ユーザーbarmanのファイル。 ファイルを編集し、これらの行を追加してから、保存して終了します。
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バックアップを使用します。