ウェブサイト検索

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

紹介

PostgreSQLは、メンテナンスの容易さ、コスト効果、他のオープンソース技術とのシンプルな統合により、ウェブおよびモバイルアプリケーション開発者に非常に人気のあるオープンソースのデータベースプラットフォームです。

PostgreSQL環境を維持するための重要な作業の一つは、データベースを定期的にバックアップすることです。バックアップは、どの組織にとっても災害復旧（DR）プロセスの一部を形成します。これはいくつかの理由から重要です。

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

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

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

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

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

PostgreSQLは2種類のバックアップ方法を提供しています：

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

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

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

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

物理バックアップは、論理バックアップとは異なり、バイナリ形式のみを扱い、ファイル単位のバックアップを作成します。物理バックアップ:

  • ポイントインタイムリカバリを提供する
  • PostgreSQLのデータディレクトリとWAL（Write Ahead Log）ファイルの内容をバックアップする
  • より大きなディスクスペースを取る
  • PostgreSQLのpg_start_backupおよびpg_stop_backupコマンドを使用してください。ただし、これらのコマンドはスクリプト化する必要があるため、物理バックアップはより複雑なプロセスになります。
  • 個々のデータベースやスキーマのみをバックアップするのではなく、全体を一度にというアプローチです。

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

バーマンバックアップの仕組み

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

Barman または バックアップおよびリカバリーマネージャー は、プロフェッショナルなPostgresソリューション会社である2ndQuadrantが提供する無料のオープンソースのPostgreSQLバックアップツールです。BarmanはPythonで書かれており、PostgreSQLインスタンスの物理バックアップと復元のためのシンプルで直感的な方法を提供します。Barmanを使用することのいくつかの利点は次のとおりです:

  • 完全に無料です
  • これは良好に保守されたアプリケーションであり、ベンダーからの専門的なサポートが利用可能です。
  • DBA/Sysadminが複雑なスクリプトやcronジョブを書いたりテストしたりする必要がなくなります。
  • 複数のPostgreSQLインスタンスを一箇所の中央ロケーションにバックアップできます
  • 同じPostgreSQLインスタンスまたは別のインスタンスに復元できます
  • ネットワークトラフィックとディスクスペースを最小限に抑えるための圧縮メカニズムを提供します

目標

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

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

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

その後、ライブデータベースからテーブルを削除して「災害」を模倣します。

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

前提条件

このチュートリアルに従うには、各々が2 GBのRAMと2つのCPUコアを持つ3つのDigitalOceanのDroplet（または独自のLinuxサーバー）を作成する必要があります。Dropletの作成の詳細には立ち入らず、こちらで詳しい情報が見つかります。

すべてのサーバーは同じOS（CentOS 7 x64ビット）を持っているべきです。

機械の名前は次のようにします:

  • メインデータベースサーバー（そのIPアドレスをmain-db-server-ipと呼ぶことにします）
  • スタンバイDBサーバー（そのIPアドレスをstandby-db-server-ipと呼びます）
  • バーマンバックアップサーバー（そのIPアドレスをバーマンバックアップサーバー-IPと呼ぶことにします）

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

各サーバーにsudoユーザーを設定し、それを一般的なアクセスに使用するべきです。ほとんどのコマンドは二つの異なるユーザー（postgres と barman）として実行されますが、それらのアカウントに切り替えるために、各サーバーにsudoユーザーも必要です。sudo権限の仕組みを理解するには、DigitalOceanのこのチュートリアルを参照してください。

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

警告： このチュートリアルでのコマンド、クエリ、または設定を本番サーバーで実行するべきではありません。このチュートリアルでは、設定を変更し、PostgreSQLのインスタンスを再起動します。正しい計画と承認なしにライブ環境でこれを行うことは、あなたのアプリケーションにとって障害を意味します。

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

最初に、main-db-server と standby-db-server に PostgreSQL 9.4 をインストールして、データベース環境を設定します。

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

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

ステップ2 — PostgreSQLの設定では、Webサーバーへのデータベースアクセスを許可するためにpg_hba.confファイルに変更を加える代わりに、Barmanサーバーが接続できるようにこの行を追加してください。barman-backup-serverのIPアドレスに続いて/32を入力します:

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

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

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

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

主データベースサーバーと待機データベースサーバーの両方にPostgreSQLがインストールされていて、バックアップサーバーからの両方へのアクセスが許可されていることを確認してください。

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

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

PostgreSQLが両方のマシンにインストールされ設定されたら、main-db-serverにサンプルデータを追加して、本番環境をシミュレートします。

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

  1. sudo su - postgres

データベースサーバーにアクセスするためにpsqlユーティリティを起動します:

  1. psql

psql プロンプトから、データベースを作成し、それに切り替えるために以下のコマンドを実行します：

  1. CREATE DATABASE mytestdb;

  2. \connect mytestdb;

出力メッセージは、ユーザーpostgresとしてデータベースmytestdbに接続したことをお知らせします。

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

  1. CREATE TABLE mytesttable1 (id integer NULL);

  2. CREATE TABLE mytesttable2 (id integer NULL);

これらはmytesttable1とmytesttable2という名前です。

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

ステップ3 — バーマンのインストール

今、バックアップサーバーにBarmanをインストールします。これにより、バックアップの管理と保存が行われます。

barman-backup-serverのこのステップを完了してください。

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

  • エンタープライズLinux（EPEL）リポジトリの追加パッケージ
  • PostgreSQLグローバル開発グループRPMリポジトリ

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

  1. sudo yum -y install epel-release

PostgreSQLリポジトリをインストールするために、これらのコマンドを実行してください。

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

  2. sudo rpm -ivh pgdg-centos94-9.4-1.noarch.rpm

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

  1. sudo yum -y install barman

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

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

ステップ4 — サーバー間のSSH接続の設定

このセクションでは、main-db-server と barman-backup-server の間、またその逆に、パスワードなしで安全に接続するためのSSHキーを設定します。

同様に、standby-db-serverとbarman-backup-serverの間にSSHキーを設定し、逆もまた然りです。

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

このチュートリアルのために、次のことを確認する必要があります:

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

SSHの仕組みの詳細には立ち入らずにおきます。SSHの基本についての非常に良い記事がDigitalOceanにあり、そちらを参照することができます。

必要なすべてのコマンドはここに含まれています。

ユーザーpostgresがmain-db-serverからbarman-backup-serverに接続するための接続設定を1回作成する方法をお見せします。

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

  1. sudo su - postgres

次のコマンドを実行してSSHキーのペアを生成してください:

  1. ssh-keygen -t rsa

キー ファイルのデフォルトの場所と名前を受け入れるには、ENTER キーを押してください。

パスフレーズなしで秘密鍵を作成するには、ENTERを2回押してください。

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

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

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

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

  1. cat ~/.ssh/id_rsa.pub

出力の内容をコピーしてください。

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

  1. sudo su - barman

以下のコマンドを実行して、.ssh ディレクトリを作成し、その権限を設定し、公開鍵の内容を authorized_keys ファイルにコピーし、最後にそのファイルを読み書き可能にします:

  1. mkdir -p ~/.ssh

  2. chmod 700 ~/.ssh

  3. echo "public_key_string" >> ~/.ssh/authorized_keys

  4. chmod 600 ~/.ssh/authorized_keys

長い公開鍵文字列が ssh-rsa で始まるように、public_key_string の代わりに、引用符の間に入れてください。

あなたはリモートサーバーの鍵をコピーしました。

さて、接続をテストするために、main-db-serverに戻り、そこから接続性をテストしてください:

  1. ssh barman@barman-backup-server-ip

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

  1. exit

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

  • 同じコマンドを再度実行します。今度は standby-db-server から barman-backup-server へ.
  • それらを三回目実行してください。今回はbarmanユーザーがbarman-backup-serverから始まり、main-db-server上のpostgresユーザーに送信されます。
  • 最後に、barmanユーザーの鍵をbarman-backup-serverからstandby-db-serverのpostgresユーザーにコピーするコマンドを実行します。

接続の両方向をテストして、新しい接続に関する最初の警告を受け入れられるようにしてください。

スタンバイDBサーバーから:

  1. ssh barman@barman-backup-server-ip

バーマンバックアップサーバーから:

  1. ssh postgres@main-db-server-ip

バーマンバックアップサーバーから:

  1. ssh postgres@standby-db-server-ip

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

ステップ5 — バックアップのためのBarmanの設定

これからBarmanを設定して、メインのPostgreSQLサーバーをバックアップします。

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

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

一つのパラメーターは configuration_files_directory で、デフォルト値は /etc/barman.d です。これは、有効にすると、Barman はそのディレクトリ内の .conf ファイルをさまざまな Postgres サーバーのバックアップ設定に使用することを意味します。メインファイルが長くなりすぎる場合は、バックアップしたい各サーバーのために別々のファイルを作成しても構いません。

このチュートリアルの簡潔さのために、すべてをデフォルトの設定ファイルに入れます。

/etc/barman.confをテキストエディタで開きます。sudoユーザー（ユーザーbarmanはそれに対して読み取り権限のみを持っています）として開いてください:

  1. 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ログは圧縮され、ベースバックアップは増分データコピーを使用します。
  • バーマンは、何らかの理由でフルバックアップが途中で失敗した場合、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

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

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

修正されたファイルの最終版は、すべてのコメントと未修正の設定を除いた形でこのようになります。

[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に最後の設定を行う必要があります。

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

  1. sudo su - barman

このコマンドを実行して、受信バックアップディレクトリを見つけてください:

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

これはこのようなものを出力するべきです。

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

incoming_wals_directoryの値をメモしてください。この例では、/var/lib/barman/main-db-server/incomingです。

今、main-db-server コンソールに切り替えてください。

現在のユーザーがすでにpostgresでない場合は、ユーザーpostgresに切り替えてください。

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

  1. 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 に異なる値がある場合は、その値を使用してください。
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を再起動する:

  1. sudo systemctl restart postgresql-9.4.service

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

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

今はBarmanがすべての設定を正しく行っているか、main-db-serverに接続できるかを確認する時間です。

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

  1. barman check main-db-server

ステップ5で/etc/barman.confファイルのサーバーブロックの中に角括弧で異なる名前を入力した場合は、その名前を使用する必要があります。

すべてが問題なければ、出力はこのようになるべきです:

barman check command output
Server 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状態について心配しないでください。これは、私たちがBarmanを設定して、最新のバックアップが1日より古くならないようにしているためです。まだバックアップは作成されていないので、チェックが失敗します。

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

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

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

  1. barman list-server

今はただ次のように表示されるはずです:

main-db-server - Main DB Server

ステップ8 — 最初のバックアップを作成する

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

次のコマンドをbarmanユーザーとしてbarman-backup-server上で実行して、最初のバックアップを取ってください:

  1. 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ディレクトリの内容をリストアップしてください:

  1. ls -l /var/lib/barman

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

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

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

バックアップの一覧

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

barman list-backup main-db-server

main-db-server 20151111T051954 - Wed Nov 11 05:19:46 2015 - Size: 26.9 MiB - WAL Size: 0 B
  • 出力の最初の部分はサーバーの名前です。この場合は、main-db-serverです。
  • 第二部 - 長い英数字の値 - はバックアップのバックアップIDです。バックアップIDは、Barmanが作成するバックアップを一意に識別するために使用されます。この場合、バックアップIDは20151111T051954です。次のステップに備えて、バックアップIDが必要です
  • 三番目の情報はバックアップがいつ作成されたかを教えてくれます。
  • 第四の部分はベースバックアップのサイズです（この場合は26.9MB）。
  • 文字列の第五部および最後の部分は、バックアップされたWALアーカイブのサイズを示しています。

バックアップの詳細を見るには、前のコマンドからサーバーの名前とバックアップID（私たちの例では20151111T051954）を使ってこのコマンドを実行してください:

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

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

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)

バックアップに含まれるファイルを詳しく確認するには、次のコマンドを実行してください:

  1. barman list-files main-db-server backup-id

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

ステップ9 — バックアップのスケジューリング

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

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

  1. crontab -e

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

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

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

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

ステップ10 — “災害”のシミュレーション

今から、あなたが作成したバックアップからどのように復元できるかを見ていきます。復元をテストするために、まず「災害」シナリオをシミュレートして、データをいくつか失ったと仮定します。

ここでテーブルを削除します。プロダクションデータベースでこれを行わないでください！

メインDBサーバー コンソールに戻り、現在のユーザーがpostgresでない場合は、ユーザーをpostgresに切り替えてください。

psqlユーティリティを開始します:

  1. psql

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

  1. \connect mytestdb;

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

  1. \dt

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

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

では、このコマンドを実行して、テーブルの1つを削除してください:

  1. drop table mytesttable2;

もし今、\dtコマンドを再実行する場合:

  1. \dt

あなたは、mytesttable1だけが残ることに気づくでしょう。

これはバックアップから復元したいデータ損失の状況の種類です。この場合、バックアップを別のサーバー、つまりスタンバイDBサーバーに復元します。

ステップ11 — リモートサーバーへの復元または移行

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

スタンバイDBサーバーに行く。

まず、sudoユーザーとしてPostgreSQLサービスを停止します。（サービスが稼働している状態で復元を実行しようとすると、再起動が失敗します。）

  1. sudo systemctl stop postgresql-9.4.service

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

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

  1. 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を使用できます。

バックアップがいつ作成されたかも確認してください。開始時刻フィールド (2016-01-14 17:35:53.164222-05:00 参照) から確認できます。

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

  1. 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 "開始時刻": show-backup コマンドから開始時刻を使用します
  • --remote-ssh-command "ssh postgres@スタンバイDBサーバーのIPアドレス": スタンバイDBサーバーのIPアドレスを使用してください
  • main-db-server: あなたの/etc/barman.confファイルからデータベースサーバーの名前を使用してください
  • バックアップ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!

今、再びstandby-db-serverコンソールに切り替えます。sudoユーザーとして、PostgreSQLサービスを開始します:

  1. sudo systemctl start postgresql-9.4.service

それでいいはずです！

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

  1. sudo su - postgres

  2. psql

mytestdbにデータベースコンテキストを切り替えて、その中のテーブルをリストしてください:

  1. \connect mytestdb;

  2. \dt



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

そのリストにはデータベース内に2つのテーブルが表示されている必要があります。言い換えれば、あなたは削除されたテーブルを復元したばかりです。

あなたの大きな回復戦略に応じて、今はスタンバイDBサーバーにフェイルオーバーしたいかもしれませんし、復元されたデータベースが正常に動作していることを確認した後、このセクションを再度実行してメインDBサーバーに復元したいかもしれません。

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

結論

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

慎重に検討した結果、BarmanはすべてのPostgreSQLデータベースの中央リポジトリになることができます。堅牢なバックアップメカニズムとシンプルなコマンドセットを提供しています。しかし、バックアップの作成は物語の半分に過ぎません。バックアップを別の場所に復元することで、常にその妥当性を確認する必要があります。この作業は定期的に行うべきです。

バーマンをバックアップ戦略に組み入れるためのいくつかの質問:

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

もう一つ注意すべき点は、Barmanが個々のデータベースのバックアップと復元を行うことができないことです。Barmanはファイルシステムレベルで動作し、すべてを一度に行うアプローチを採用しています。バックアップ中は、インスタンス全体とそのすべてのデータファイルがバックアップされ、復元時にはそれらすべてのファイルが復元されます。同様に、Barmanではスキーマのみやデータのみのバックアップを実行することもできません。

したがって、pg_dumpやpg_dumpallを使用した論理バックアップとBarmanを使用した物理バックアップの両方を活用するように、バックアップ戦略を設計することをお勧めします。この方法により、個別のデータベースを迅速に復元する必要がある場合は、pg_dumpバックアップを使用できます。時点復元のためには、Barmanバックアップを使用してください。

関連記事: