災害復旧計画では、目標復旧時点（RPO）は、失う余裕のあるデータの量を決定する主要な復旧パラメーターです。 RPOは、秒から日までの時間でリストされます。事実上、RPOはバックアップシステムに直接依存しています。これは、通常の操作を再開するために回復する必要があるバックアップデータの経過時間を示します。
毎晩午後10時にバックアップを行う場合。そして、データベースシステムは午後3時に修復できないほどクラッシュします。翌日、最後のバックアップ以降に変更されたものはすべて失われます。この特定のコンテキストでのRPOは前日のバックアップです。つまり、1日分の変更を失う余裕があります。
災害復旧に関するホワイトペーパーの以下の図は、その概念を示しています。
ただし、RPOを厳しくする場合は、バックアップだけでは不十分な場合があります。データベースをバックアップするときは、実際には特定の時点でのデータのスナップショットを取得しています。そのため、バックアップを復元するときに、最後のバックアップと失敗の間に発生した変更を見逃すことになります。
ここで、ポイントインタイムリカバリ（PITR）の概念が登場します。
PITRとは何ですか？
ポイントインタイムリカバリ（PITR）は、その名前が示すように、過去の任意の時点でデータベースを復元することを含みます。これを実行できるようにするには、バックアップを復元してから、バックアップ後に発生したすべての変更を障害の直前まで適用する必要があります。
PostgreSQLの場合、変更はWALログに保存されます（WALとそれらが保存するデータの詳細については、このブログを確認してください）。
したがって、PITRを実行できるようにするために確認する必要があるのは、バックアップとWALの2つです（それらの継続的なアーカイブを設定する必要があります）。
PITRを実行するには、バックアップを回復してからWALを適用する必要があります。
いつ役に立ちますか？
この戦略は、データの破損の原因となった問題から復元するときにいつでも使用できます。データの損失を最小限に抑えようとしていることを覚えておく必要がありますが、それ以降はデータが役に立たなくなる可能性のある問題がいくつかあります。
この例としては、計画外のデータ変更（DMLまたはDDL）、メディア障害、またはデータ破損につながるデータベース保守（アップグレードなど）があります。問題の後に発生したデータの変更を復元することはできません。
ユーザーが誤ってDMLを実行し、テーブル全体のデータが誤って変更または削除されたとしましょう。別の場所でデータベースのPITRを実行してから、テーブルの内容をエクスポートできます。次に、そのテーブルを既存のデータベースに復元して、問題が発生する前のテーブルのコピーに効果的にロールバックできます。
もちろん、この方法でデータベースの一部のみを復元できるとは限らないため、その場合は、すべてのデータベースを特定のポイントに復元する必要があり、データの損失は最小限に抑えられます（見逃してしまいます）。問題が発生した後に発生した変更）
ClusterControlで使用するにはどうすればよいですか？
以前のブログでは、PITRを手動で実装する方法を確認できましたが、次に、ClusterControlを使用してこのタスクを実行する方法を確認しましょう。
ポイントインタイムリカバリの有効化
PITR機能を有効にするには、WALアーカイブを有効にする必要があります。これを行うには、ClusterControl->PostgreSQLクラスターの選択->ノードアクション->WALアーカイブの有効化に移動するか、ClusterControl->PostgreSQLクラスターの選択->バックアップ->設定に移動して[ポイントインタイムリカバリを有効にする]オプションを有効にします。 （WAL Archiving）」を次の画像に示します。
WALアーカイブを有効にするには、データベースを再起動する必要があることに注意する必要があります。 ClusterControlは私たちのためにもこれを行うことができます。
「バックアップディレクトリ」や「バックアップ保持期間」などのすべてのバックアップに共通のオプションに加えて、ここではWAL保持期間を指定することもできます。デフォルトは0で、これは永久を意味します。
WAL Archivingが有効になっていることを確認するには、ClusterControl-> Select PostgreSQL Cluster-> Nodesでマスターノードを選択すると、次の画像に示すように、WALArchivingEnabledメッセージが表示されます。
ポイントインタイムリカバリと互換性のあるバックアップの作成
前の手順で見たように、WALアーカイブを有効にすると、PITRと互換性のあるバックアップを作成できます。これを行うには、ClusterControl-> PostgreSQL Cluster-> Backup->CreateBackupを選択します。
新しいバックアップを作成するか、スケジュールされたバックアップを構成できます。この例では、単一のバックアップを即座に作成します。
ここでは、PITRと互換性のあるメソッド「pg_basebackup」、バックアップの取得元のサーバー（PITRと互換性を持たせるには、マスターである必要があります）、およびバックアップを保存する場所を選択する必要があります。対応するボタンを有効にすることで、バックアップをクラウド（AWS、Google、またはAzure）にアップロードすることもできます。
次に、圧縮、暗号化、およびバックアップの保持の使用を指定します。
バックアップセクションでは、バックアップの進行状況と、方法、サイズ、場所などの情報を確認できます。
バックアップからのポイントインタイムリカバリ
バックアップが完了したら、ClusterControlPITR機能を使用してバックアップを復元できます。このため、バックアップセクション（ClusterControl-> PostgreSQLClusterの選択->Backup）で、[バックアップの復元]を選択するか、復元するバックアップを直接[復元]することができます。
ここで、復元するバックアップとディレクトリを選択します。
[ノードに復元]オプションを選択したままにして、続行します。
次に、バックアップを復元する場所を選択し、PITRオプションを有効にする必要があります。時間を指定することで、回復するまでの時間になります。 UTCタイムゾーンが使用され、マスターのPostgreSQLサービスが再起動されることを考慮してください。
ClusterControlの[アクティビティ]セクションから復元の進行状況を監視できます。
結論
PITRは、タイトなRPOを満たすために必要な機能です。正しい災害復旧計画を確実にするために、正しく設定する必要があります。 ClusterControlは、PostgreSQLデータベースにPITRを実装するのに役立つ使いやすいインターフェイスを提供します。