RPO は、最後のコピーが届いた地点で決まる

第6期で見た WAL は、同じ機械のクラッシュ回復に使うログでした。これを別の場所へ運んでおくと、別の実体の上で好きな時刻まで再生できます。PostgreSQL 文書 §25.3 はこう書きます。

Thus, this technique supports point-in-time recovery: it is possible to restore the database to its state at any time since your base backup was taken.

条件は、ベースバックアップの開始まで遡る continuous sequence of archived WAL files があることです。問題は、WAL がいつ外へ出るかです。§19.5 は次のように書きます。

The archive_command or archive_library is only invoked for completed WAL segments.

WAL は既定で 16MB ずつのセグメントに分かれ(normally 16MB apiece)、アーカイブは閉じたセグメントにしか走りません。 書き込みが少なければ、コミット済みの変更が長くプライマリの中にしか無い状態が続きます。§25.3 は there could be a long delay between the completion of a transaction and its safe recording in archive storage と書いています。

NIST SP 800-34 Rev.1 は RPO をこう定義します。

The RPO represents the point in time, prior to a disruption or system outage, to which mission/business process data can be recovered (given the most recent backup copy of the data) after an outage.

NIST が前提にしているのは「最新のバックアップのコピー」までで、WAL アーカイブを論じているわけではありません。ここから先は PostgreSQL 文書と実演で支えます。WAL アーカイブでは、そのコピーが閉じたセグメントの単位で届きます。

これで両向きの誤りが見えます。

• 「PITR なら任意の時点へ損失ゼロで戻れる」は誤り。届いていない WAL には戻れません(MODE A・B)。
• 「ベースバックアップの間隔がそのまま損失の幅」も誤り。ベースバックアップは1回のまま、70秒待って …04 がアーカイブされた後は、DELETE の直前へ 150 行で戻れました(MODE C、2回)。

既存クイズの解説「RPOが短いほど頻繁なバックアップが必要になります」は正しい文です。WAL を使う構成では、その「頻繁さ」に WAL を外へ出す間隔が入ります。その上限を決めるのが archive_timeout です。

To limit how old unarchived data can be, you can set archive_timeout to force the server to switch to a new WAL segment file periodically.

§25.3 は archive_timeout settings of a minute or so are usually reasonable とし、短すぎるとアーカイブが膨らむと書きます。それより速く外へ出したいなら、§19.5 は You should consider using streaming replication, instead of archiving と続けます。