バックアップことはじめ　JPUG第29回しくみ＋アプリケーション分科会(2014-05-31)

© 2014 Metro Systems.
バックアップことはじめ
第29回しくみ＋アプリケーション勉強会
2014年5月31日
株式会社メトロシステムズ
佐藤　千佳

2
自己紹介
氏名：佐藤　千佳（さとう　ちか）
所属：株式会社メトロシステムズ
メールアドレス：satock@metrosystems.co.jp
過去：
商用DBMS使って動いているシステムの保守
現在：
PostgreSQLなどDBMSの性能みています
近況と未来：
北海道（OSC北海道2014）行ってきます

3
はじめに…
「しくみ＋アプリケーション勉強会」ですが、
運用系の話をします
「えぇ～」と感じた方は次回の「第30回しくみ＋アプリ
ケーション勉強会」にもご参加ください！

4
アジェンダ
基礎編
一般編
PostgreSQL編
実践編
pg_dump / pg_dumpall
pg_start_backup()とpg_stop_backup()
pg_basebackup
pg_rman
amanda
Barman

基礎編（一般編）

6
運用管理の格言
論よりバックアップ！
　
転ばぬ先のバックアップ！！

7
バックアップとは
万が一の事態に備えてデータを別の記憶媒体に保存するこ
と

8
万が一ってどんなとき？
ハードウェア故障
HDDの故障、サーバの電源異常
破壊行為や盗難 …等
ソフトウェア故障
OS壊れた…
ヒューマンエラー
人間だもの…
操作ミス
アプリケーションのエラーによる論理破壊 …等
災害
地震、雷、火事、洪水 …等

9
バックアップの役割
「万が一」のデータ損失時に備え、データを復旧するため
のデータを取得しておくこと
バックアップはデータを復旧するための手段にすぎない
復旧に使えないバックアップは『バックアップ』ではありません
バックアップしていた積りなのに…
バックアップの戻し方が分からない…
弊社の故障対策は万全です！
だって
　ディスクの冗長化（ミラーリング）しています
　勿論、バックアップも取得しています
けど、
ミラーを組んでいたディスクが同時に
全て故障…
バックアップしていたファイルはなぜか
読み込めず…

10
バックアップの取得にはどのような方法があるのか
OSコマンドでコピー
cp コマンド、tar コマンド、rsync コマンド　…等
ストレージの機能を使ってコピー
スナップショット機能　…等
商用のバックアップソフトを使ってコピー
I○M、HI○ACHI、Fu○itsu　…等
DBMSの機能を使ってコピー

11
これはバックアップになりますか？
ディスクをミラーリングしている
レプリケーションまたはDR構成をとっている
十分ではありません
　・ミラーごと壊れたら終わりです
　・ヒューマンエラーなどの論理破壊には対応できません
十分ではありません
　・ヒューマンエラーなどの論理破壊には対応できません

12
バックアップ領域
論理バックアップのイメージと用語
時間
バックアップ
表の定義や格納されているデー
タなどを抽出
日曜日
金曜日
データベース
DB1
DB2
データベース
DB1
DB2
データベース
DB1
DB2
--- 社員表テーブル定義
CREATE TABLE 社員(
・・・
);
--- 社員表のデータ
INSERT INTO 社員(
101, 佐藤
);
・・・
リストア
バックアップデータを再ロード
リストア後のデータベースは
バックアップ取得時点の内容

13
物理バックアップのイメージと用語
時間
変更
ログ
変更
ログ
バックアップ
データベースを構成するファイルの
コピーを別の場所に保存
リカバリ
バックアップ取得以降にデータベース
に行われた変更ログを反映
日曜日
金曜日
データベース
DB1
DB2
データベース
DB1
DB2
データベース
DB1
DB2
データベース
DB1
DB2
リストア
バックアップファイルを破損した
ファイルの代わりに配置

14
物理バックアップのイメージと用語
時間
変更
ログ
変更
ログ
バックアップ
データベースを構成するファイルの
コピーを別の場所に保存
リカバリ
バックアップ取得以降にデータベース
に行われた変更ログを反映
日曜日
金曜日
データベース
DB1
DB2
データベース
DB1
DB2
データベース
DB1
DB2
データベース
DB1
DB2
リストア
バックアップファイルを破損した
ファイルの代わりに配置
リストアのみの場合
　データベースはバックアップ取得時点の内容
リカバリまで行った場合
　データベースはクラッシュ直前の内容まで戻せる
　（変更ログが残っている場合）

基礎編（PostgreSQL）

16
PostgreSQLバックアップの種類
論理バックアップ
物理バックアップ
オフライン・バックアップ
オンライン・バックアップ

17
論理バックアップの特徴
お勧めPOINT
サービスを継続したままバックアップが取得できる
CPU アーキテクチャの異なるマシンにリストアできる
異なるバージョン間でのデータ移行に使用できる
データのみ、スキーマのみ…など自由度の高いバックアップ
注意点
バックアップを取得したタイミングまでにしか復旧できない
設定ファイルなどのバックアップが別途必要になる

18
物理バックアップの特徴（１）
オフライン・バックアップ（コールドバックアップ）
お勧めPOINT
手順がシンプル
設定ファイルから丸ごとバックアップできる
リストア直後にデータベースを起動できる
注意点
バックアップ取得時はデータベースを停止する必要がある
バックアップを取得したタイミングまでにしか復旧できない
バックアップ対象はデータベース・クラスタ全体
（テーブル単位、データベース単位の操作はできない）
データベースを正常に停止した状
態でバックアップを取得

19
物理バックアップの特徴（２）
オンライン・バックアップ（ホットバックアップ）
お勧めPOINT
サービスを継続したままバックアップが取得できる
指定した任意の日時までリカバリできる
故障発生直前の最新の状態までリカバリできる
注意点
バックアップのリストア後にリカバリ操作をする必要がある
アーカイブログ運用している必要がある
バックアップ対象はデータベース・クラスタ全体
（テーブル単位、データベース単位の操作はできない）
データベースを停止せず
にバックアップを取得

20
PostgreSQLバックアップに必要な３点セット
①テーブルデータのバックアップファイル
②DDL、スキーマ情報など
⇒ バックアップ取得時に①に含めることができる
③パラメータファイル
①データベースクラスタの
バックアップファイル
②WAL
（ベースバックアップ）
②WAL
③アーカイブWALログ

21
PostgreSQLバックアップに必要な３点セット
①テーブルデータのバックアップファイル
②DDL、スキーマ情報など
⇒ バックアップ取得時に①に含めることができる
③パラメータファイル
②WAL
（ベースバックアップ）
②WAL
③アーカイブWALログ
アーカイブログモードで運用
している必要がある
具体的には postgresql.conf の以下のパラメータを変更
-----
wal_level = archive 　　# PostgreSQL9.0 ~
archive_mode = on
archive_command = '/bin/cp -i %p /mnt/server/archivedir/%f'

22
色々あるけどバックアップは何を取れば良いの？（１）
リカバリ要件が決まればバックアップの方法がある程度限定される
検討すべきこと
想定されるリカバリパターンごとにリカバリ要件・計画を検討する
リカバリパターン
ディスク故障が発生した場合
APやヒューマンエラーによる論理破壊の場合
データセンターそのものが消失した場合　…等
リカバリ要件の明確化
故障からの復旧に掛けられる時間は？
どの時点のデータに復旧すればよい？
全てのデータを漏れなく復旧する必要はある？
リカバリ計画の検討
故障発生時、どのような手順で復旧できるか？
復旧までにどれくらいの時間がかかるか？
リカバリ手順の検証
リカバリ計画を実現するために、「いつ」「どこに」「どのような」バックアップを取るか...を考える
保存場所
保存方針（セキュリティ等）
保存期間
削除方法
バックアップを取得する上での制限も考慮する
バックアップ取得中にシステムは停止できる？
バックアップ取得中にフロントにあたえる負荷はどこまで許容できるか？
バックアップ取得ために掛けられる時間は？
バックアップシステムに掛けられる予算は？

23
色々あるけどバックアップは何を取れば良いの？（２）
基本的にはどこまで復旧したいのかでバックアップ方法は決まる
A)バックアップ取得時点まで戻せればOK
B)バックアップ取得から故障発生までのどこかの時点
C)故障発生直前まで
バックアップを取得する上での制限も考慮する
バックアップ取得中にシステムは停止できる？
時間
(A)
バックアップ取得時点
バックアップ
DB1
DB2
(C)
障害発生直前
（完全リカバリ）
(B)
この間のどこか
（不完全リカバリ）

24
A :
B :
色々あるけどバックアップは何を取れば良いの？（３）
復旧したいポイントは？
　Ａ：バックアップ取得時点
　Ｂ：バックアップ取得以降～障害発生直前までのどこか（障害発生直前含む）
バックアップ中にデータベースは停止で
きますか？
　Ａ：停止できる
　Ｂ：停止できない
バックアップ中にデータベースは停止で
きますか？
　Ａ：停止できる
　Ｂ：停止できない
オフライン・
バックアップ
※ 設定ファイルも忘れずに…
＋
アーカイブWALログ
＋
WAL
＋
アーカイブWALログ
＋
WAL

25
こんな故障の時はどうしたら良いの？
①インスタンス障害が発生した！
②参照専用のマスタテーブルを削除してしまった！
③ユーザ情報、テーブル、データベースを削除してしまった！
④データベースクラスタを格納しているディクスが壊れた！
⑤WAL領域のディスクが壊れた or アーカイブされる前のWALを削除してし
まった！
⑥アーカイブWALログ領域のディスクが壊れた or 削除してしまった！
⑦パラメータファイル(postgresql.conf/pg_hba.conf)を削除してしまった！

26
こんな故障の時はどうしたら良いの？ ①
①インスタンス障害が発生した！
停電、プロセス故障などによりデータベースが異常終了してしまいインス
タンス（メモリ＋プロセス）上の情報が失われる
メモリ上の変更がファイルに反映されていない可能性がある（データの
不整合）
データベースを再起動すればOK（クラッシュリカバリ）

27
こんな故障の時はどうしたら良いの？ ②
② 参照専用のマスタテーブルを削除してしまった！
ベースバックアップからデータベースクラスタをリストア
アーカイブWALログを用いてリカバリ
WALが残っている場合は完全リカバリまで可能
または
論理バックアップからテーブル名を指定してリストア
WAL1
データベースクラスタ
DB1 DB2
時間
WAL2 WAL3 WAL4 WAL5
アーカイブログ領域
WAL1 WAL2 WAL3
pg_xlog
テーブル

28
こんな故障の時はどうしたら良いの？ ③
③ユーザ情報、テーブル、データベースを削除してしまった！
WALが残っている場合は完全リカバリ可能
WAL1
DB1 DB2
時間
WAL2 WAL3 WAL4 WAL5
WAL1 WAL2 WAL3
pg_xlog

29
こんな故障の時はどうしたら良いの？ ④
④データベースクラスタを格納しているディクスが壊れた！
WALが残っている場合は完全リカバリ可能
WAL1
DB1 DB2
時間
WAL2 WAL3 WAL4 WAL5
WAL1 WAL2 WAL3
pg_xlog

30
こんな故障の時はどうしたら良いの？ ⑤
⑤WAL領域のディスクが壊れた or アーカイブされる前のWALを削除してし
まった！
アーカイブWALログにある変更分までリカバリ可能
（不完全リカバリ）
WALが壊れているため完全リカバリできない
WAL1
DB1 DB2
時間
WAL2 WAL3 WAL4 WAL5
WAL1 WAL2 WAL3
pg_xlog

31
こんな故障の時はどうしたら良いの？ ⑥
⑥アーカイブWALログ領域のディスクが壊れた or 削除してしまった！
サービスへの影響は直ぐにはない
ディスク故障の場合、不要になったWALをアーカイブできないためWAL
領域（pg_xlog 領域）にログが蓄積され続ける
⇒ いずれWAL領域を圧迫するためアーカイブWALログ領域を復旧させる
ベースバックアップを再度取得する必要がある
⇒ ベースバックアップ再取得前にデータベースが壊れると復旧できない
WAL1
DB1 DB2
時間
WAL2 WAL3 WAL4 WAL5
WAL1 WAL2 WAL3
pg_xlog

32
こんな故障の時はどうしたら良いの？ ⑦
⑦パラメータファイル(postgresql.conf/pg_hba.conf)を削除してしまった！
サービスへの影響は直ぐにはない
新たなパラメータファイルを配置する
WAL1
DB1 DB2
時間
WAL2 WAL3 WAL4 WAL5
WAL1 WAL2 WAL3
pg_xlog
pg_hba.conf

33
基礎編のまとめ
バックアップは失ったデータを復旧するために取ります
バックアップを取るだけではなく、データを戻す準備もきちんとし
ましょう
想定されるリカバリパターンはちゃんとテストする
リカバリ手順の確立とドキュメント化する
基本的な知識を身に着けましょう

実践編

35
実際にバックアップを取得してみる
OSコマンド、ストレージスナップショットなどを利用
⇒ 今回ここは割愛
pg_start_backup()/pg_stop_backup()
pg_basebackup
pg_rman
amanda
Barman

36
pg_dump
pg_dumpall

37
論理バックアップを取得するツール
pg_dump :
テーブル単位、データベース単位にバックアップ
pg_dumpall：
データベースクラスタ内の全てのデータベースの内容をバックアップ
バックアップの取得形式によってリストア方法が異なる
psql または pg_restore コマンドでリストア

38
pg_dump / pg_dumpall まとめ
コマンド対応表
バックアップ
コマンド
バックアップ
単位
出力形式
リストア
コマンド
pg_dump
テーブル単位
データベース単位
平文（SQL) psql
カスタム
pg_restoreディレクトリ
tar
pg_dumpall 全てのデータベース平文(SQL) psql

39
pg_start_backup() / pg_stop_backup()

40
オンライン・バックアップを取得する際に実行する関数
これを実行することでバックアップ取得中に発生したデータベースへの変
更ログ（WAL)が「どこから」「どこまで」なのかをPostgreSQLに教える
pg_start_backup(label) ：ベースバックアップ取得開始前に実行
pg_stop_backup() ：ベースバックアップ取得完了後に実行
ベースバックアップ取得完了後にアーカイブWALログとWALをバックアッ
プする
時間
データベース
クラスタ
DB1
WAL1 WAL2 WAL3
WAL1 WAL2 WAL3
WAL4
pg_xlog

41
WAL1 WAL2 WAL3
WAL1 WAL2 WAL3
WAL4
pg_xlog
プする
時間
データベース
クラスタ
DB1
pg_stop_backup()
バックアップ取得中…
pg_start_backup()

42
WAL1 WAL2 WAL3
WAL1 WAL2 WAL3
WAL4
pg_xlog
プする
時間
データベース
クラスタ
DB1
pg_stop_backup()
バックアップ取得中…
pg_start_backup()
ベースバックアップ＋アーカイブWALログ＋ WAL
のセットで整合性の取れたデータ

43
pg_basebackup

44
pg_basebackup
オンライン・バックアップを取得するためのコマンド（PG9.1～）
リモートからの操作でベースバックアップが取得できる
レプリケーションプロトコル使用
バックアップ取得用のDBサーバのOSアカウントが不要になる
REPLICATION権限があればスーパーユーザでなくても利用可能
max_wal_senders パラメータをバックアップ取得用に 1 ～ 2 増やす
パラメータの変更にはデータベースの再起動が必要
ベースバックアップ取得と並行してWALをストリームする場合は値を
2 増やす（ -X s オプション）
[satock@backup]$ pg_basebackup -D /array_1/satock/pgdata_basebkf -X s -P -h dbserver1 -U repl
102640/102640 kB (100%), 1/1 tablespace

45
pg_rman

46
pg_rman とは
NTT OSSセンタで開発されたオンライン・バックアップと
リストアの補助ツール
PostgreSQL Recovery Manager の略
Sourceforgeで管理
http://sourceforge.net/projects/pg-rman/
最新バージョンは pg_rman 1.2.8（2014-03-31 リリース）

47
pg_rman の特徴
全体オンライン・バックアップの取得
増分バックアップの取得
複数サーバのバックアップ取得
バックアップの圧縮（gzip）
リテンションポリシーの管理
自動メンテナンス機能
ストレージ・スナップショットをサポート

48
動作要件
Linux/Unix 系 OS に対応
Windows 未対応
PostgreSQL 8.2 以上
データベースサーバ、バックアップサーバの PostgreSQL
メジャーバージョンが一致していること
PostgreSQL8.1 以下は未サポート

49
pg_rman を使ってみる（１）
事前準備（バックアップカタログの初期化）
　
　
バックアップ取得
フルバックアップ
　
　
　
増分バックアップ
　
　
　
バックアップの検証
[satock@server2]$ pg_rman init -B /array_1/satock/pg_rman/sever2 -D ~/pgdata
INFO: ARCLOG_PATH is set to '/home/satock/arc'
INFO: SRVLOG_PATH is set to '/home/satock/pgdata/pg_log'
[satock@server2]$ pg_rman backup –b full -B /array_1/satock/pg_rman/server2 -D ~/pgdata
INFO: database backup start
NOTICE: pg_stop_backup complete, all required WAL segments have been archived
[satock@server2]$ pg_rman backup -b incremental -B /array_1/satock/pg_rman/server2 -D
~/pgdata
INFO: database backup start
NOTICE: pg_stop_backup complete, all required WAL segments have been archived
[satock@server2]$ pg_rman validate -B /array_1/satock/pg_rman/server2 -D ~/pgdata
INFO: validate: 2014-05-29 11:29:01 backup and archive log files by CRC

50
pg_rman を使ってみる（２）
リストア
その他の管理コマンド
pg_rman delete DATE
指定した DATE より前に取得したバックアップを削除
削除対象に最新のフルバックアップが含まれる場合は削除できない
pg_rman show
バックアップ履歴を表示
pg_rman show timeline
取得済みバックアップのタイムラインとバックアップモードを表示
[satock@server2]$ pg_rman restore -B /array_1/satock/pg_rman/server2 -D ~/pgdata
INFO: validate: 2014-05-29 11:29:01 backup and archive log files by SIZE
INFO: validate: 2014-05-29 11:50:39 backup and archive log files by SIZE
INFO: restore complete. Recovery starts automatically when the PostgreSQL server is started.
[satock@server2]$ pg_ctl start -D ~/pgdata

51
amanda

52
amanda とは
メリーランド大学で開発されたパブリックドメインのバックアップユー
ティリティ
The Advanced Maryland Automatic Network Disk Archiver の略
無料のコミュニティ版と有料のエンタープライズ版がある
最新バージョンは amanda-3.3.5（2013-12-10 リリース）
PostgreSQL用プラグイン ampgsql を用いることでオンライン・バッ
クアップを取得できる
amanda-3.1.0 から提供されている API
perl で書かれている

53
amanda を使ったバックアップの特徴
バックアップの圧縮（gzip）

54
動作要件
幅広い OS に対応
Linux/Unix 系 OS
Windows
MacOS
データベースサーバ側に tar 1.17 以上が必要
注意
テーブルスペースのバックアップは未サポート

55
amanda を使ったバックアップ
事前準備
amandabackup をスーパーユーザとして登録
amanda.conf、amanda-client.conf など必要なファイルの設定
ここでは割愛…
バックアップの取得と確認
バックアップレベルは amanda 側の判断になる
FULLバックアップか WAL のみバックアップするか
[amandabackup@backup DailySet1]$ sudo -u amandabackup amdump DailySet1
[amandabackup@backup DailySet1]$ /usr/sbin/amadmin DailySet1 find
date host disk lv tape or file file part status
2014-05-29 11:56:14 server1 postgres 0 DailySet1-01 1 1/1 OK
2014-05-29 12:19:36 server1 postgres 1 DailySet1-02 1 1/1 OK

56
amanda を使ったリストア、リカバリ
リストアとリカバリ
　
　
　
　
　
　
amrecover を使うと対話式にすすめられる
amrestore は…
recovery.conf を作成し、データベースを起動したら完了
recovery.conf の作成を自動化することも可能
[amandabackup@backup DailySet1]$ sudo amrecover
AMRECOVER Version 3.3.5. Contacting server on localhost ...
220 alma AMANDA index server (3.3.5) ready.
Setting restore date to today (2014-05-29)
200 Working date set to 2014-05-29.
：

57
Barman

58
Barman とは
イタリアの2ndQuadrant社によって開発された
PostgreSQLサーバ用のバックアップ・リカバリマネー
ジャツール
Backup and recovery manager の略
Sourceforgeで管理
http://sourceforge.net/projects/pgbarman/files/
最新バージョンは Barman 1.3.2（2014-04-15 リリース）

59
Barman の特徴
ローカル/リモートでのバックアップ&リカバリ
WALを圧縮してバックアップ(bzip2, gzip, custom)
バックアップ時のI/O、ネットワーク帯域の上限指定

60
動作要件
Linux/Unix 系 OS に対応
Windows 未対応
PostgreSQL 8.4 以上
データベースサーバ、バックアップサーバの PostgreSQL メジャー
バージョンが一致していること
Python 2.6 or 2.7
Python module
argcomplete
argh >= 0.21.2
psycopg2
python-dateutil
rsync >= 3.0.4
各サーバ間でパスワードレス SSH 接続がで
きること
バックアップサーバからデータベースに
（スーパーユーザで）接続できること

61
Barman のインストール
Barmanをインストールする 2 つの方法
1.yum, apt-get を使ってインストール
2.ソースからインストール
[satock@backup]$ cd ~/barman-1.3.2
[satock@backup]$ ./setup.py build
running build
running build_py
running build_scripts
[satock@backup]$ sudo ./setup.py install
running install
running bdist_egg
running egg_info
　　：
　　：
six 1.6.1 is already the active version in easy-install.pth
Using /usr/lib/python2.6/site-packages/six-1.6.1-py2.6.egg
Finished processing dependencies for barman==1.3.2

62
Barman を使う前の準備
バックアップを格納する親ディレクトリの作成
barman.conf の作成
docs ディレクトリ内にサンプル conf ファイルがある
デフォルトでは /etc/barman 配下に格納(Barman1.2.1 ～)
[satock@backup]$ vim /etc/barman/barman.conf
：
：
[barman] ★ barman セクション
; Main directory
barman_home = /array_1/satock/barman ★ バックアップ格納の親ディレクトリ
; System user
barman_user = satock ★ barman 実行ユーザ
：
：
[dbserver1] ★ バックアップ対象サーバごとの設定
;; ; Human readable description
description = "Main PostgreSQL Database"
;;
;; ; SSH options
ssh_command = ssh postgres@dbserver1 ★ DBサーバ接続への SSH コマンド
;;
;; ; PostgreSQL connection string
conninfo = host=dbserver1 user=postgres ★ PostgreSQL への接続ホストとユーザ名

63
設定の確認（１）
バックアップ対象サーバの取得
各バックアップ対象サーバの詳細情報の取得
[satock@backup]$ barman list-server
dbserver1 - Main PostgreSQL Database
dbserver2 - Server2 PostgreSQL Database
[satock@backup]$ barman show-server dbserver1
Server dbserver1:
active: True
archive_mode: on
backup_directory: /array_1/satock/barman/dbserver1
　　　　：
　　　　：
basebackups_directory: /array_1/satock/barman/dbserver1/base
compression: gzip
conninfo: host=dbserver1 user=postgres
　　　　：
　　　　：
incoming_wals_directory: /array_1/satock/barman/dbserver1/incoming
last_shipped_wal: 0000000700000001000000F8
　　　　：
　　　　：
ssh_command: ssh postgres@dbserver1
tablespace_bandwidth_limit: None
wal_retention_policy: main
wals_directory: /array_1/satock/barman/dbserver1/wals

64
設定の確認（１）
バックアップ対象サーバの取得
各バックアップ対象サーバの詳細情報の取得
[satock@backup]$ barman list-server
dbserver1 - Main PostgreSQL Database
dbserver2 - Server2 PostgreSQL Database
[satock@backup]$ barman show-server dbserver1
Server dbserver1:
active: True
archive_mode: on
backup_directory: /array_1/satock/barman/dbserver1
　　　　：
　　　　：
basebackups_directory: /array_1/satock/barman/dbserver1/base
compression: gzip
conninfo: host=dbserver1 user=postgres
　　　　：
　　　　：
incoming_wals_directory: /array_1/satock/barman/dbserver1/incoming
last_shipped_wal: 0000000700000001000000F8
　　　　：
　　　　：
ssh_command: ssh postgres@dbserver1
tablespace_bandwidth_limit: None
wal_retention_policy: main
wals_directory: /array_1/satock/barman/dbserver1/wals
アーカイブWALログの転送先
postgresql.conf 内 archive_command パラメータのアーカイブWALログ出力
先と一致していること
e.g.
archive_command = 'rsync -a %p
satock@backup:/array_1/satock/barman/dbserver1/incoming/%f'

65
設定の確認（２）
設定ファイルの確認
バックアップディレクトリが存在しない場合は自動で作成
[satock@backup]$ barman check dbserver1
Server dbserver1:
ssh: OK
PostgreSQL: OK
archive_mode: OK
archive_command: OK
directories: OK
retention policy settings: OK
compression settings: OK
minimum redundancy requirements: OK (have 0 backups, expected at least 0)

66
バックアップの取得
barman backup コマンドでバックアップ取得
# dbserver1 のバックアップ取得
#（allオプション付与で全てのバックアップ対象サーバのバックアップ取得）
[satock@backup]$ barman backup dbserver1
Starting backup for server dbserver1 in /array_1/satock/barman/dbserver1/base/20140521T145558
Backup start at xlog location: 1/23000020 (000000070000000100000023, 00000020)
Copying files.
Copy done.
Asking PostgreSQL server to finalize the backup.
Backup end at xlog location: 1/230000A8 (000000070000000100000023, 000000A8)
Backup completed
–immediate_checkpoint オプション付与でバックアップ前に強制
チェックポイントを発行
barman.conf パラメータでも指定可能
immediate_checkpoint = true (def. false)

67
その他の管理コマンド
barman cron
メンテナンスコマンド
アーカイブWALログをWALバックアップディレクトリに移動する
barman list-backup
ベースバックアップのリスト
barma show-backup
ベースバックアップの詳細情報
barman list-files
ベースバックアップの構成ファイル一覧
barman delete
ベースバックアップと関連するアーカイブログの削除

68
リストアとリカバリ
barman recover コマンドでリストア＆リカバリ
--remote-ssh-command オプション付与でリモートリカバリ
e.g.
　
PITR のオプション
--target-tli ：タイムライン指定
--target-time ：タイムスタンプ指定
--target-xid ： XID指定
--target-name(PG9.1~) ： pg_create_restore_point で作成したポイント指定
テーブルスペースの再配置
--tablespace ：テーブルスペースの配置先指定
注意
シンボリックリンクを使っている場合はリストア後に再作成する（pg_xlogとか…）
リストアされた postgresql.conf の archive_command パラメータを環境にあわせ
て書き換える
[satock@backup]$ barman recover --remote-ssh-command "ssh satock@dbserver2" dbserver1
20140524T195903 /home/satock/recover_pgdata

69
その他の設定パラメータ
retention_policy
bandwidth_limit
tablespace_bandwidth_limit

70
実践編　まとめ
pg_dump pg_dumpall
pg_start_
backup()
＋
cp,tar など
pg_base
backup
pg_rman amanda Barman
対応OS
Linux
Windows(*)
Linux
Windows(*)
Linux
Linux
Windows(*)
Linux
バックアップ
タイプ
論理
物理
（オンライン）
バックアップ
単位
テーブル /
データベース
データベース
クラスタ
(FULL)
データベース
クラスタ(FULL /
増分) ,
WAL
データベース
クラスタ(FULL) ,
WAL
どこまで戻せるバックアップ時点任意の時点
アーカイブログ
運用の必要性
不要必要
自動メンテ
ナンス機能
なしなしあり
クライアント
環境からの実施
可能不可可能不可可能可能
(*)動作未検証

ありがとうございました。

バックアップことはじめ　JPUG第29回しくみ＋アプリケーション分科会(2014-05-31)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to バックアップことはじめ　JPUG第29回しくみ＋アプリケーション分科会(2014-05-31)

Similar to バックアップことはじめ　JPUG第29回しくみ＋アプリケーション分科会(2014-05-31) (20)