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

手順

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