9.4.6.3.5. 継続的なアーカイブバックアップを使用したデータベースの復元

手順

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 ファイルでクライアント認証設定を復元して接続できるようにします。