■バックアップ／リカバリ
データベースへのアクセスとは簡単に言えば、ディスク上にデータを効率良く配置し、それをいかに速く読み出したり、書き出したりするかということにつきる。ハードディスクは機械的な回転装置であり、非常に精密な精度で動作している。耐久性は全体的には向上しつつあるとはいえ、コンピュータを構成するパーツの中でも寿命は長いほうではなく、消耗部品のひとつと言える。
ディスク障害に対する対策としてはいわゆるRAID＊5構成が最近ではよく使われ、パフォーマンスと安定性を両立させるRAID0+1や、RAID5などが使われる。最近のサーバでは一般的な構成で、個人ユースでも100Gバイトを超えたディスクが当たり前となり、バックアップデバイスの価格が相対的に高い現状もあり、ハイエンドユーザーを中心に普及している。
メーカー製のサーバではディスクのホットスワッピング（稼働中の交換）ができるものも少なくない。
しかし、これらの手段はミスオペレーションによるデータ喪失を防ぐものではないし、サーバそのものの損傷やコントローラ障害といった、確率的にはディスク障害より小さいものの、事象としては十分に想定しうる事態には対応できない。よって、適切なバックアップとリカバリの計画やシミュレーションは不可欠である。
どのようなバックアップを行うかは、システムの構成やデータ容量、RDBMS製品によっても異なってくる。
たとえばOracleを例に取ると、Oracleにはいくつかのバックアップ手段が用意されており、それを必要に応じて選択することができる。主たるバックアップ手段は論理バックアップと物理バックアップである（図4）。
論理バックアップはエクスポートと呼ばれており、データベースの内部情報をバックアップする。リカバリ時にはOracleの基本システムまで復活させておいて、実データは論理バックアップデータからインポートというツールで復活させる。サイズの大きなデータベースでは、全体のバックアップを取った後、差分のみバックアップするということも可能である。
これは元々、Oracleのメジャーバージョンアップ時などのデータ移行のための手段であったが、比較的小規模なシステムやある程度のダウンタイムが許容されるシステムでのバックアップ手段としてもよく用いられる。
もうひとつの手段としては、物理バックアップがある。これはOracleのデータベースの実データが格納されているテーブル領域を構成するファイルを、丸ごとバックアップするもので、通常のバックアップ方式である。Oracleにはアーカイブログモードとノーアーカイブログモードという2つのモードがあり、ノーアーカイブログモードでは物理ファイルのバックアップを取るにはデータベースを停止することが必須となる。
一方、アーカイブログモードでは、データベース稼働中にも物理バックアップが可能なほか、アーカイブログという更新差分データのみからなるログファイルを作成するので、一度全体バックアップを取得しておけば、通常はこの差分データのみのバックアップで済むのでバックアップに要する時間が短くなる。
また、実データファイル、ログファイル、アーカイブファイルなどを適切な物理ボリューム配置（たとえば異なるディスク上）にしておけば、本体データベースがディスク損傷で失われても、全体バックアップとアーカイブログバックアップの適用により、比較的簡単なオペレーションで障害直前までのデータベースの完全回復が可能となる。またアーカイブログの保存日付などを活用することにより、指定した日時に近い状態のデータベースの状態に復旧させることもできる。これは重大なオペミスやバグなどにより、テーブルが大きく損傷を受けたときなどに有効な手段である。このような機能の充実は信頼性にベースを置いてきたOracleの大きな特徴といえる。
Oracleのバックアップとリカバリに関しては、その詳細を述べていくとそれだけで数百ページの本が1冊書ける内容となってしまう。より詳しくは書籍も多数出ているのでそちらを参照してほしい。
もう1つのRDBMSとして、PostgreSQLを見てみよう。
PostgreSQLの場合は、まずpg_dumpというツールが挙げられる。これは次のようなコマンド操作をすることにより、データベースの内容をSQLスクリプトとして吐き出すことができる。
$ pg_dump test1 > test1.dat
pg_dumpコマンド自体は標準出力に結果を出力するので、ファイルに保存するには上記のようにリダイレクトを用いる。復旧は、PostgreSQLの対話型ツールであるpsqlコマンドを使う。
$ psql -d test1 -f test1.dat
このバックアップはOracleの論理バックアップ／リストアであるエクスポート／インポートに似ているが、PostgreSQLの特徴は、バックアップファイルの内容をすべてピュアなテキストの形でSQL込みで出力することであろう。当然、Linuxの標準的なコマンド体系を使用しているので、大容量データの時はgzipなどを結合しテキストデータを圧縮できるし、リダイレクト先にテープデバイスを指定すれば、そのままテープに出力も可能である（エクスポート／インポートとダイレクトエクスポートを除くと内部的にはSQLを発行しているが、それを普通のユーザーが直接見たり修正することは想定されていない）。
PostgreSQLにおいても物理バックアップは可能である。PostgreSQL自体のマニュアルでは、データの実体ファイルは/usr/local/pgsql/data配下に置くことが推奨されているが、この設定は実際には導入しているディストリビューションごとのPostgreSQLの設定で異なっている可能性が高い。自分からPostgreSQLをインストールした状態でない限りは、ディストリビューションのマニュアルかサポートでPostgreSQLのオーナユーザーを確認し、そのユーザーの環境変数「PGDATA」を確認したほうがよいだろう。
たとえば、MIRACLE LINUX 2.1では、この変数は、
PGDATA=/var/lib/pgsql/data
となっている。この場合は、/var/lib/pgsql/dataの配下をバックアップする必要がある。またこの物理バックアップを取得する場合、PostgreSQLデータベースは停止させておく必要がある。
先のpg_dumpバックアップもデータベース稼働中に可能ではあるが、更新やデータベースの構造変更（テーブル自体の追加削除、列の追加削除など）を行ってない時にバックアップする必要がある。また、データベースの更新動作が高負荷で行われている最中は、その実行はあまり好ましくないので、このあたりは運用で工夫が必要となる。
データファイルの二重化などについては、RAID構成をうまく使って対応していくことになる。それよりも、PostgreSQLを使うメリットは、そのオペレーションの簡便さや他のLinuxの操作系、言語などとの結合性の良さが魅力となるので、それを活かすような使い方をすべきであろう。
なお、ここで書いたことは2003年9月現在のPostgreSQL 7.3、およびPostgreSQL 7.2.3 での状況である。これらの状況は変わりうるものであることも付記しておく。
