Red Hat Training
A Red Hat training course is available for RHEL 8
9.4.6.3.5. 継続的なアーカイブバックアップを使用したデータベースの復元
継続バックアップを使用してデータベースを復元するには、以下の手順を行います。
手順
サーバーを停止します。
# systemctl stop postgresql.service
必要なデータを一時的な場所にコピーします。
必要に応じて、クラスターデータのディレクトリー全体と、すべてのテーブル空間をコピーします。既存データベースのコピーを 2 つ保持するには、システムに十分な空き領域が必要になることに注意してください。
十分な容量がない場合は、クラスターの
pg_wal
ディレクトリーの内容を保存します。これには、システムがダウンする前にアーカイブされなかったログが含まれます。- クラスターデータディレクトリー、および使用しているテーブル空間のルートディレクトリー下の既存ファイルおよびサブディレクトリーをすべて削除します。
ベースバックアップからデータベースファイルを復元します。
以下の点を確認してください。
-
ファイルは、正しい所有権 (
root
ではなくデータベースシステムのユーザー) で復元されます。 - ファイルは、正しい権限で復元されます。
-
pg_tblspc/
サブディレクトリーのシンボリックリンクが正しく復元されます。
-
ファイルは、正しい所有権 (
pg_wal/
サブディレクトリーにあるファイルをすべて削除します。このファイルは、ベースバックアップから作成されるため、非推奨になりました。
pg_wal/
をアーカイブしていない場合は、適切な権限で再作成します。-
手順 2 で保存したアーカイブされていない WAL セグメントファイルを
pg_wal/
にコピーします。 クラスターデータディレクトリーの
recovery.conf
リカバリーコマンドファイルを作成し、restore_command
設定パラメーターにシェルコマンドを指定します。cp
コマンド、別のコマンド、またはシェルスクリプトを使用できます。以下に例を示します。restore_command = 'cp /mnt/server/archivedir/%f "%p"'
サーバーを起動します。
# systemctl start postgresql.service
サーバーは復元モードに入り、引き続き必要なアーカイブファイル (WAL) を読み込みます。
外部エラーにより復元が終了した場合は、サーバーを再起動して復元を続行します。復元プロセスが完了すると、サーバーは
recovery.conf
の名前をrecovery. done
に変更します。これにより、サーバーが通常のデータベース操作を開始した後に、誤ってリカバリーモードに戻るのを防ぐことができます。データベースのコンテンツを確認して、データベースが必要な状態に復元されたことを検証します。
データベースが必要な状態に復元されていない場合は、手順 1 に戻ります。データベースが必要な状態に復元された場合は、
pg_hba.conf
ファイルでクライアント認証設定を復元して接続できるようにします。
継続バックアップを使用した復元の詳細は、PostgreSQL ドキュメンテーション を参照してください。