バックアップの概要と方式一覧
NTT オープンソースソフトウェアセンタ 鈴木 幸市
本記事では、PostgreSQLデータベースのバックアップとリストア方法を解説していきます。 今回は、各種バックアップの概要を説明し、次回以降でそれぞれの方法の具体的な手順を示していきます。
用語の整理
「バックアップ」とは、データベースの障害に備えたり、アップグレードの際にデータを移行するために、データベースの内容を別のファイルに取り出すことをいいます。 バックアップには、データをSQLやテキストデータとして取り出す「論理バックアップ」と、データファイルをそのまま保存する「物理バックアップ」があります。
論理バックアップでは SQL の結果としてデータを保存するので、もちろん PostgreSQL サーバは動作したままです。 一方、物理バックアップでは、サーバを停止した状態でバックアップを行う「オフライン・バックアップ」と、サーバを起動したまま行う「オンライン・バックアップ」があります。
「リストア」とは、バックアップで取り出したデータベースの内容を元に戻したり、他のデータベースにデータを再投入することをいいます。 また、「リカバリ」という用語も良く使われますが、本記事ではデータベースを障害から復元することをリカバリと呼んでいます。
1. バックアップとリストア方法
PostgreSQLデータベースのバックアップとリストアは複数の方法で行うことができるようになっています。 概要を表1に示します。 バックアップの方法に対応してリストアの方法もある程度決まってきます。 バックアップが不要なリストア、リストアが不要なバックアップもあります。 これらを以下に解説していきます。
| 名称 | バックアップ方法 | リストア方法 | 復旧時点 | バックアップ所要時間 |
|---|---|---|---|---|
| クラッシュ・リカバリ | (バックアップは不要) | 再起動時に自動的に行われる | システム障害直前の最新状態 | --- |
| 論理バックアップ | サーバを起動したまま、SQLとして保存 (pg_dump, pg_dumpall) | SQLを再投入 (pg_restore, psql) | バックアップ開始時点 | 長い |
| オフライン・バックアップ | サーバを停止し、ファイルをコピーする。 | サーバ停止状態でファイルをコピーする。 | バックアップ開始時点 | 短い |
| オンライン・バックアップ | サーバを起動したまま、ファイルをコピーする。WALをアーカイブする。 | サーバ停止状態でファイルをコピー後、最新状態または任意時刻までリカバリを行う。 | バックアップ終了直後から最新状態の間の任意の時点 | 短い |
2. バックアップとリストアの概要
2.1 クラッシュ・リカバリ
クラッシュ・リカバリは、正確にはバックアップでは無いのですが、関係が深いので最初に説明します。
PostgreSQL プロセス自身や、これが動作しているOSやマシンがクラッシュした場合であっても、ファイルシステムに問題がない場合は、PostgreSQL が次に起動したときに自動的にリカバリが行われ、データベースが整合性を保った状態に復旧します。 クラッシュした時点で実行中のトランザクションはアボートされ、クラッシュした時点でコミット済みのトランザクションの実行結果はデータベースに反映されます。
これらの一連の動作はPostgreSQLを起動した時点で自動的に実行され、基本的に外部からは操作できません。 リカバリが実行されたことは、PostgreSQLの運転ログ (格納場所は設定ファイル postgresql.conf で指定) を見るとわかります。
2.2 論理バックアップ - SQLでのバックアップ
論理バックアップでは、データベースの内容をSQLとして取り出します。 元のデータベースにリストアするだけでなく、メジャーバージョンやプラットホームの異なるPostgreSQLや、場合によっては別のDBMS製品へのデータ移行に使うこともできます。 PostgreSQLはMVCC (多版方式) でデータを管理しているため、バックアップ中に更新を行うこともできます。 バックアップ開始直前の状態の一貫性のある状態で、バックアップを取得できます。
利点は、PostgreSQLに接続できればリモートからでもバックアップが取得できること、バックアップとリストアの対象を柔軟に選択できること、リストアする際に既存のデータベースにバックアップの内容を追加することが挙げられます。
一方、欠点は、オフライン・バックアップやオンライン・バックアップに比べると、バックアップやリストアに必要な時間は長くかかる傾向があることです。1つのトランザクションとしてバックアップを実行するため、同時に更新処理がある場合にはロング・トランザクションによる弊害も心配です。
2.3 オフライン・バックアップ
オフライン・バックアップと次に述べるオンライン・バックアップでは、データベースを構成するファイルすべて ($PGDATA ディレクトリ以下すべて) 丸ごとバックアップします。
オフライン・バックアップでは、データベースを停止させてデータベースクラスタのバックアップを取得します。 バックアップは tar や rsync など、通常のファイルをバックアップの手段を使います。 リストアする場合も、PostgreSQLが停止した状態でバックアップしたファイルを書き戻し、PostgreSQLを再起動するだけです。
デフォルト以外のテーブル空間を使用している場合は、$PGDATA 配下のファイルだけでなく、 テーブル空間に割り当てられたディレクトリ配下の全てのファイルもバックアップし、リストア時も同じパスに書き戻す必要があります。 特に、異なるサーバにデータベースを移行する場合は注意が必要です。
オフライン・バックアップの利点は、バックアップやリストアに必要な時間はもっとも短くて済むことです。 しかし、欠点として、PostgreSQLを停止する必要があるのでサービスが止まり、メジャーバージョンアップにも使うことはできません。 システムのアップデートの際には役に立ちますが、日常的に使うバックアップとしては採用は難しいでしょう。
2.4 オンライン・バックアップ
データベースを運転したままバックアップを取得する方法です。 バックアップは、オフライン・バックアップと同様に、通常のファイルをバックアップするツールを使って取得します。 これを「ベースバックアップ」と呼びます。 ベースバックアップ取得の際、ファイルがバックアップ中に削除されることに対応したツールを使う必要があります。 そのため、tar よりも rsync を使うほうが安全です。 テーブル空間を使っている場合の注意点はオフライン・バックアップと同じです。
ベースバックアップの取得中もデータベースは更新されていきますので、これとは別にアーカイブログも取得する必要があります。 リストアの際には、ベースバックアップとアーカイブログの両方を使うため、通常のデータベースの運転開始とは異なる手順が必要になります。
オンライン・バックアップの利点は、PostgreSQLを止めずに、かつ比較的短時間でバックアップを取得できることです。 また、リストアの際にデータベースの状態を最新のものにすることも、任意の時刻の状態に戻すこともできます。 一方欠点は、オフライン・バックアップと同様にメジャーバージョンアップには使えません。
各バックアップの具体的な使い方は、連載の中で解説していきます。