Tech Sketch Bucket of Technical Chips by TIS Inc.

Amandaを使ってバックアップ(PostgreSQL編)

Pocket

データベースのバックアップは、停止状態ならば単なるファイルコピーだけで非常に簡単ですが、実際の運用においてはシステムを止めることができないことも良くあります。
Amandaでは、PostgreSQL用のプラグイン「ampgsql」が提供されており、バックアップ時に使用することでオンラインバックアップが可能です。
今回はampgsqlでPostgreSQLのオンラインバックアップ~リカバリの手順が正常に実施できることを確認してみました。


AmandaのPostgreSQL用ツール「ampgsql」

Amanda では「ampgsql」というプラグインで PostgreSQL のオンラインバックアップが行えます。なお、ampgsql の実体は以下の処理を呼び出す Perl スクリプトで、PostgreSQLドキュメントの
24.3. 継続的アーカイブとポイントインタイムリカバリ(PITR) に沿った手順を実装しているようです。

インストール時の注意

ampgsqlを使用する場合、DBサーバ側にGNU Tar ver1.17以上が必要です。内部でtarの--transformオプションを使用しているため、バージョンが古い場合、「ERROR /bin/tar: unrecognized option `--transform'」というエラーになってバックアップが失敗します。(普通のファイルバックアップであれば古いバージョンでも問題ありません。)
CentOS5.x系の場合、標準ではver1.15.1という古いバージョンのためアップデートが必要ですが、
新しいバージョンのパッケージが提供されていない ため、以下の手順でソースからコンパイルする必要があります。

 # cd /usr/local/src
 # wget http://ftp.gnu.org/gnu/tar/tar-1.26.tar.gz
 # tar xzvf tar-1.26.tar.gz
 # cd tar-1.26
 # rpm -e --nodeps tar
 # ./configure FORCE_UNSAFE_CONFIGURE=1
 # make
 # make install

本記事ではAmanda本体のセットアップと基本設定については完了している前提で、ampgsqlを使うための追加手順のみ扱います。

PostgreSQL側の設定

アーカイブ保存設定の手順についてはPostgreSQLドキュメント 24.3.1. WALアーカイブの設定 を参照してください。

amandabackupをPostgreSQLのスーパーユーザとして登録
 $ createuser -s amandabackup -P

ユーザ登録時に設定したパスワードは、後で使うために控えておいてください。

pg_hba.conf

amandabackupユーザの認証設定を追記

amanda-server側設定

amanda.conf

今回はバックアップ時にampgsqlを使用するバックアップ方式を追加します。バックアップに使用するコマンドのカスタマイズには、application-tool定義を設定する必要があります。

disklist

[ホスト名 ディスク名 PostgreSQLのデータディレクトリ ダンプ方式]の書式で記入します。
ホスト名:DBサーバのホスト名を記入します。
ディスク名:適当でかまいませんが、DB名などのほうがわかりやすいでしょう。
ダンプ方式:amanda.confで設定したdumptype定義の名称(dt_ampgsql) とあわせます。

amanda-clients側設定

/etc/amanda/pg_passfile(新規作成)
 # su - amandabackup
 $ echo 'pgsql_sv:*:*:amandabackup:上記で設定したパスワード' > /etc/amanda/pg_passfile
 $ chmod 600 /etc/amanda/pg_passfile
amanda-client.conf

サンプル設定としてamanda-server側の/var/lib/amanda/example/amanda-client-postgresql.confが提供されていますので、内容をコピーして使います。(残念ながら、サンプルファイルがあるのはamanda-server側のみです。)

※archive_commandで設定した保存先がシンボリックリンクになっている場合の注意
Amanda側で設定するPG-ARCHIVEDIRに設定するパスはリンク先のディレクトリ(実際にアーカイブログが保存されている場所)にする必要があります。リンクのままの場合、以下のようなエラーになります。

 # sudo -u amandabackup amcheck DailySet1
    :
 Amanda Backup Client Hosts Check
 --------------------------------
 ERROR: pgsql_sv: PG-ARCHIVEDIR /var/postgresql/archive is NOT a directory
 ERROR: pgsql_sv: PG-ARCHIVEDIR /var/postgresql/archive is NOT readable
 ERROR: pgsql_sv: PG-ARCHIVEDIR /var/postgresql/archive is NOT executable
 ERROR: pgsql_sv: /var/lib/pgsql is executable? No
 Client check: 1 host checked in 1.316 seconds. 4 problems found.
 
 (brought to you by Amanda 3.3.2)

以上の設定が完了したら、amcheckコマンドで設定の確認を実施し、エラーの出た箇所を修正します。

ちなみに、amcheckコマンド実行時は以下のようなチェックを行っています。

  • 設定ファイル
  • フォルダの存在・パーミッション
  • PostgreSQLへの接続・ログイン

amcheckの結果が「 0 problems found.」になったら設定は完了です。

バックアップ&リカバリ動作確認

バックアップ、リカバリ時のコマンド使用法はコールドバックアップ時と特に変わりません。

下記動作確認ではフルバックアップ取得後、わざとデータベースクラスタを破壊(消去)して、バックアップ取得時点のデータに戻せることを確認します。

バックアップ前データ確認
 # /etc/init.d/postgresql-9.0 start
 postgresql-9.0 サービスを開始中: [ OK ]
 
 # sudo -u postgres psql -c " select count (*) from pgbench_history;" testdb
 could not change directory to "/root"
 Password:
  count
 -------
  19120
 (1 row)
バックアップサーバ側(backup_sv)でフルバックアップ取得

実際の運用ではcronによるスケジュール起動ですが、今回はテストのため手動実行します。

 # sudo -u amandabackup amdump DailySet1
 # sudo -u amandabackup amadmin DailySet1 find (←結果確認)
 
 date host disk lv tape or file file part status
 2013-01-31 14:59:47 pgsql_sv testdb 0 DailySet1-01 1 1/1 OK
PostgreSQL強制終了、dataディレクトリ削除

ファイルシステムの復元確認のため、dataディレクトリを削除します。

 # sudo -u postgres pg_ctl stop -m immediate
 # rm -rf /var/lib/pgsql/9.0/data
リカバリ

公式ドキュメントの 24.3.3. 継続的アーカイブによるバックアップを使用した復旧 の手順3~5相当の部分は「amrecover」コマンドを使用します。(手順2、6のpg_xlogの退避はバックアップ時点に戻す目的であれば不要のため省略。)

 # amrecover
 AMRECOVER Version 3.3.2. Contacting server on backup_sv ...
 220 backup_sv AMANDA index server (3.3.2) ready.
 Setting restore date to today (2013-01-31)
    :
 amrecover> setdisk testdb
 amrecover> lcd /var/lib/pgsql/9.0
 amrecover> add *
 Added file /PostgreSQL-Database-0
 amrecover> extract
   :
 Continue [?/Y/n]? y
 
 amrecover> quit
 200 Good bye.
recovery.conf作成、PostgreSQL再起動

recovery.confの作成は手作業です。自動化の方法は後述します。

 # echo restore_command = "'cp /var/lib/pgsql/9.0/archive/%f \"%p\"'" > /var/lib/pgsql/9.0/archive/data/recovery.conf
 # /etc/init.d/postgresql-9.0 start
 postgresql-9.0 サービスを開始中: [ OK ]
 #
リカバリ後データ確認

データベースクラスタ削除前と同じデータが復元されていることを確認します。

 # sudo -u postgres psql -c " select count (*) from pgbench_history;" testdb
 could not change directory to "/root"
 Password:
  count
 -------
  19120
 (1 row)

無事、復元されていました。

recovery.confの作成も自動化する

先ほどの動作確認ではrecovery.confを手動で作成しましたが、ユーザスクリプトを組合わせることでこの作業を自動化することが出来ます。

amanda-clients側:/usr/libexec/amanda/application/mkrecovery (ユーザスクリプト本体)

amanda.conf編集
リカバリ完了後にユーザスクリプトを実行するための設定を追加します。

これで、amrecover完了後、PostgreSQLサーバの再起動だけでリカバリが完了するようになりました。

動作確認

リカバリ後、復元したdataディレクトリにrecovery.conf が自動作成されていることを確認します。

 # amrecover
   :
 amrecover> lcd /var/lib/pgsql/9.0
   :
 amrecover> quit
 200 Good bye.
 # cat /var/lib/pgsql/9.0/archive/data/recovery.conf
 restore_command = 'cp /var/lib/pgsql/9.0/archive/%f "%p"'
 # /etc/init.d/postgresql-9.0 start
 postgresql-9.0 サービスを開始中: [ OK ]
 # ls -l /var/lib/pgsql/9.0/archive/data
 合計 128
   :
 -rw-r--r-- 1 root root 58 1月 31 15:14 2013 recovery.done (←リカバリが完了してリネームされたrecovery.conf)

まとめ

今回試したampgsqlと同様の処理をコマンド1発で実行するツールとしては pg_rmanpg_basebackup (ver9.2~)がありますが、専用のツールでなくAmandaを利用する場合、次のような利点があります。

  1. データベース以外のバックアップとの一元管理
  2. ファイルバックアップと全く同一の保存/復元操作手順
  3. バックアップ先の選択肢が広がる

バックアップサーバなどの準備不要な分専用ツールの方が手っ取り早くバックアップが取れますが、データベース以外のデータもバックアップする場合「○○用の手順はこれ、××用の手順はこれ...」とあれこれ覚える必要が無いので余裕の無いことの多いリカバリ作業においては助かりそうです。

次回はバックアップをAmazonS3に保存するカスタマイズについてご紹介します。

エンジニア採用中!私たちと一緒に働いてみませんか?