はじめに

Postgresqlにはいくつかバックアップ・リストアの方法があります。
それぞれの種類に応じてどのような時にどのような方法を用いればよいかまとめました。
具体的な手順については各種記事が出ておりますので、ここでは触れませんが要件に応じて何を選択すれば良いか?という指針の立て方がわからないという方向けになります。

定期的なバックアップおよび復元 (論理バックアップ)

要件として、復元地点が例えば日単位などある程度目標値が高くない場合については pg_dumpを定期的に実行します。
バックアップの形式にもいくつかありますが大きくは平文とカスタム形式の2種類でしょう。ほとんどの場合、カスタム形式でバックアップした方が圧縮されますし復元も早いのでお勧めします。
あえて平文を選択する意図としては、可読性に優れている点、必要な部分が限定されている場合抜き出しやすい点差分検出がしやすい点でしょう。

定期的な取得はcronを使用するか、Jenkinsなどのツールを使うのも良いでしょう。
https://www.postgresql.jp/document/16/html/app-pgdump.html
https://www.postgresql.jp/document/16/html/app-pgrestore.html

PITRを使ったバックアップおよび復元 (オンライン物理バックアップ)

要件として特定の地点、主に障害発生直前までや、ある操作の直前まで復元する必要がある場合は PITRを選択します。
起点となるバックアップを取得して、復旧する地点までのWALファイルを適用させるという方式です。
設定がいくつか必要ですし、postgresqlのファイル構成を多少知らないといけませんので論理バックアップよりは少し難しい面があります。
どの程度のトランザクションがあるかにもよりますが、定期的にpg basebackupとWALの退避を行うとよいでしょう。

具体的な方法については公式記事やポータルサイトなどを参照ください。
https://www.postgresql.jp/document/16/html/continuous-archiving.html
https://lets.postgresql.jp/documents/technical/backup/4

ファイルコピーによるバックアップ(オフライン物理バックアップ)

postgresqlは究極的にはただのファイルですので、対象を全てコピーしてしまうという手段もとることができます。
具体的にはDBを停止してpostgresqlのディレクトリをtarなどで固め、復元場所に展開した後起動するという内容となります。
通常の運用ではあまり使用するケースは考えられませんが、定期的なバックアップを取得し災害時に復旧を図るためであったり、テスト環境へのコピーを作成する場合であったりの場合に使用します。

レプリケーションを用いたバックアップ(その他)

レプリケーションを用いてバックアップの用途を果たすという方法もあります。
マスタ側で障害が発生した場合、スレーブ側に切り替えて運用を行うようなことを想定する場合です。一方で基盤側に自動でマイグレーションするような仕組みがあれば同等のことを行うことは可能と考えます。

終わりに

今回はバックアップ・リカバリについてご紹介いたしました。
いくつかバックアップの種類はありますが、用途に応じて使い分ける必要があります。 DB単位での備えも必要ですが、基盤側で補えるようなエラーケースも存在するため、
使用する環境に応じて必要な処置を検討する必要があるでしょう。
どれか一つを選択するというよりは、以下の障害に対して要件やコストに応じて必要な設定・対処を行う必要があるというところとなります。

ハードウェア故障
データの損失や破損
ソフトウェアバグやエラー
人為的ミス
セキュリティ侵害