4.5. PostgreSQL データのバックアップ

手順

1. 新しいデータベースを作成します。

   $ createdb dbname

2. ダンプされたデータベースのオブジェクトを所有するか、オブジェクトに対する権限が許可されたユーザーがすべて存在していることを検証してください。このようなユーザーが存在しない場合、復元は元の所有権と権限でオブジェクトの再作成に失敗します。

3. psql ユーティリティーを実行して、pg_dump ユーティリティーが作成したテキストファイルのダンプを復元します。

   $ psql dbname < dumpfile

   ここでの dumpfile は、pg_dump コマンドの出力になります。非テキストファイルのダンプを復元するには、代わりに pg_restore ユーティリティーを使用します。

   $ pg_restore non-plain-text-file

手順

1. ダンプされたデータベースのオブジェクトを所有するか、オブジェクトに対する権限が許可されたユーザーがすべて、すでに存在していることを検証してください。このようなユーザーが存在しない場合、復元は元の所有権と権限でオブジェクトの再作成に失敗します。

2. psql ユーティリティーを実行して、pg_dumpall ユーティリティーにより作成されたテキストファイルのダンプを復元します。

   $ psql < dumpfile

   ここでの dumpfile は、pg_dumpall コマンドの出力になります。

手順

1. データベースクラスターの場所を選択し、このクラスターを初期化します。

   # postgresql-setup --initdb

2. postgresql サービスを停止します。

   # systemctl stop postgresql.service

3. 任意のメソッドを使用してファイルシステムのバックアップを作成します (例: tar アーカイブ)。

   $ tar -cf backup.tar /var/lib/pgsql/data

4. postgresql サービスを起動します。

   # systemctl start postgresql.service

1. WAL ファイルのアーカイブ手順をセットアップおよびテストします。WAL アーカイブ を参照してください。
2. ベースバックアップを実行します。ベースバックアップ を参照してください。

手順

1. /var/lib/pgsql/data/postgresql.conf ファイルで以下を行います。

   1. wal_level 設定パラメーターを replica 以降に設定します。
   2. archive_mode パラメーターを on に設定します。
   3. archive_command 設定パラメーターでシェルコマンドを指定します。cp コマンド、別のコマンド、またはシェルスクリプトを使用できます。

2. postgresql サービスを再起動して、変更を適用します。

   # systemctl restart postgresql.service

3. アーカイブコマンドをテストし、既存のファイルが上書きされないこと、失敗した場合にゼロ以外の終了ステータスが返されることを確認します。
4. データを保護するには、セグメントファイルがグループまたはワールド読み取りアクセスを持たないディレクトリーにアーカイブされていることを確認してください。

手順

1. pg_basebackup ユーティリティーを使用してベースバックアップを実行します。

   • 個々のファイル (プレーン形式) としてベースバックアップを作成するには、以下を実行します。

     $ pg_basebackup -D backup_directory -Fp

     backup_directory は、任意のバックアップの場所に置き換えます。

     テーブル空間を使用し、サーバーと同じホストでベースバックアップを実行する場合は、--tablespace-mapping オプションも使用する必要があります。そうしないと、バックアップを同じ場所に書き込もうとすると、バックアップが失敗します。

   • tar アーカイブ (tar および圧縮形式) としてベースバックアップを作成するには、以下を実行します。

     $ pg_basebackup -D backup_directory -Ft -z

     backup_directory は、任意のバックアップの場所に置き換えます。

     このようなデータを復元するには、ファイルを正しい場所に手動で抽出する必要があります。

2. ベースバックアッププロセスが完了すると、バックアップ履歴ファイルで指定されている、データベースクラスターのコピーとバックアップ中に使用された WAL セグメントファイルを安全にアーカイブします。
3. ベースバックアップで使用されている WAL セグメントファイルよりも数値が小さい WAL セグメントを削除します。これらはベースバックアップよりも古く、復元には必要ないためです。

手順

1. サーバーを停止します。

   # systemctl stop postgresql.service

2. 必要なデータを一時的な場所にコピーします。

   必要に応じて、クラスターデータのディレクトリー全体と、すべてのテーブル空間をコピーします。既存データベースのコピーを 2 つ保持するには、システムに十分な空き領域が必要になることに注意してください。

   十分な容量がない場合は、クラスターの pg_wal ディレクトリーの内容を保存します。これには、システムがダウンする前にアーカイブされなかったログが含まれます。

3. クラスターデータディレクトリー、および使用しているテーブル空間のルートディレクトリー下の既存ファイルおよびサブディレクトリーをすべて削除します。

4. ベースバックアップからデータベースファイルを復元します。

   以下の点を確認してください。

   • ファイルは、正しい所有権 (root ではなくデータベースシステムのユーザー) で復元されます。
   • ファイルは、正しい権限で復元されます。
   • pg_tblspc/ サブディレクトリーのシンボリックリンクが正しく復元されます。

5. pg_wal/ サブディレクトリーにあるファイルをすべて削除します。

   このファイルは、ベースバックアップから作成されるため、非推奨になりました。pg_wal/ をアーカイブしていない場合は、適切な権限で再作成します。

6. 手順 2 で保存したアーカイブされていない WAL セグメントファイルを pg_wal/ にコピーします。

7. クラスターデータディレクトリーの recovery.conf リカバリーコマンドファイルを作成し、restore_command 設定パラメーターにシェルコマンドを指定します。cp コマンド、別のコマンド、またはシェルスクリプトを使用できます。以下に例を示します。

   restore_command = 'cp /mnt/server/archivedir/%f "%p"'

8. サーバーを起動します。

   # systemctl start postgresql.service

   サーバーは復元モードに入り、引き続き必要なアーカイブファイル (WAL) を読み込みます。

   外部エラーにより復元が終了した場合は、サーバーを再起動して復元を続行します。復元プロセスが完了すると、サーバーは recovery.conf の名前を recovery. done に変更します。これにより、サーバーが通常のデータベース操作を開始した後に、誤ってリカバリーモードに戻るのを防ぐことができます。

9. データベースのコンテンツを確認して、データベースが必要な状態に復元されたことを検証します。

   データベースが必要な状態に復元されていない場合は、手順 1 に戻ります。データベースが必要な状態に復元された場合は、pg_hba.conf ファイルでクライアント認証設定を復元して接続できるようにします。