こんにちは、現場の最前線でデータベースの設計と運用に明け暮れている、あなたの「技術の兄貴分」です。
今日は、PostgreSQLを扱うエンジニアにとっての「究極の守護神」とも言える技術、PITR（Point-in-Time Recovery：ポイントインタイムリカバリ）についてお話ししましょう。
「間違えて本番データを消してしまった……」
「1時間前の状態に戻せれば、この大惨事を防げたのに……」
データベースエンジニアなら、一度は背筋が凍るような想像をしたことがあるはずです。pgAdmin 4というツールは、単なるクエリ実行ツールではありません。こうした「万が一」の事態からシステムを救い出すための強力なコクピットになります。
今回は、初心者の方でも迷わないように、「過去の特定の時刻にデータベースを巻き戻す」という魔法のような手順を、シミュレーション形式で丁寧に解説します。これをマスターすれば、あなたはチームから「神」と呼ばれる存在になるでしょう。
—
1. PITR（ポイントインタイムリカバリ）とは何か？
まず、概念を理解しましょう。PITRは、単なる「バックアップからの復元」とは次元が違います。
PostgreSQLにはWAL（Write-Ahead Log）という仕組みがあります。これは、データへの変更内容をすべて記録した「航海日誌」のようなものです。
- ベースバックアップ： ある時点のデータの丸ごとコピー（写真）
- WAL： その後に行われたすべての変更履歴（ビデオ）
この2つを組み合わせることで、「○月○日 10時15分30秒の状態」というピンポイントの時刻に、データベースを正確に再現できるのです。これがPITRです。
—
2. 事前準備：WALアーカイブを有効にする
PITRを行うには、PostgreSQL側で「航海日誌（WAL）」を保存する設定（アーカイブモード）にする必要があります。これができていないと、後から「戻したい」と思っても手遅れです。
まず、`postgresql.conf` を開き、以下の設定を確認・変更してください。
postgresql.conf の設定例
アーカイブモードをONにする
archive_mode = on
WALファイルを保存するコマンド（OSに合わせてディレクトリを作成してください）
%p はWALのパス、%f はファイル名に置換されます
archive_command = ‘test ! -f /var/lib/postgresql/archive/%f && cp %p /var/lib/postgresql/archive/%f’
WALのレベルをレプリカ（または論理）に設定
wal_level = replica
設定変更後は、PostgreSQLサービスの再起動が必要です。
—
3. ステップ・バイ・ステップ：PITRシミュレーション
それでは、実際にpgAdmin 4を使いながら、悲劇からの生還を体験してみましょう。
Step 1: 「ベースライン」のバックアップを取る
まずは、平和な時の状態を保存します。
1. pgAdmin 4で対象のデータベースを右クリック。
2. [Backup…] を選択。
3. `Filename` に `base_backup.sql` などと入力し、`Format` を `Tar` に設定（PITRではファイルベースのバックアップが基本ですが、今回は手順の理解のためにpgAdminのGUIを活用します）。
4. [Backup] を実行。
Step 2: データの更新（日常業務）
ここで、正常なデータ操作を行います。
— 正常なデータ追加
INSERT INTO employees (name, salary) VALUES (‘田中太郎’, 500000);
— この時点の時刻をメモしておいてください（例: 2023-10-27 10:00:00）
Step 3: 悲劇の発生（誤操作）
恐ろしいことが起きました。誰かが `WHERE` 句を忘れて `DELETE` を実行してしまいました！
— 【大惨事】全社員データを消してしまった！
DELETE FROM employees;
— 実行時刻: 2023-10-27 10:05:00
Step 4: 運命のリカバリ作業
さあ、Step 2の「10:00:00」の状態に戻しましょう。
1. PostgreSQLサービスを停止します。（稼働したままの復旧はできません）
2. データディレクトリ（通常 `main` や `data`）内のファイルを、念のため別の場所に退避させます。
3. Step 1で取った「ベースバックアップ」をデータディレクトリに展開します。
4. データディレクトリ直下に、`recovery.signal` という名前の空ファイルを作成します。これが「今はリカバリ中だよ」という合図になります。
5. `postgresql.conf`（または `postgresql.auto.conf`）に、ターゲットとなる時刻を追記します。
どの時点まで履歴を再生するかを指定する
recovery_target_time = ‘2023-10-27 10:00:00’
指定した時刻に到達したら、データベースを読み取り専用で開く
recovery_target_action = ‘pause’
Step 5: データベースの再起動と確認
PostgreSQLサービスを起動します。
ログを確認すると、PostgreSQLがアーカイブからWALを読み込み、10:00:00の状態まで自動的に「ビデオを早送り」してくれる様子が見えるはずです。
pgAdmin 4で接続し、データを確認してください。消したはずの「田中太郎」さんが戻っていれば成功です！
最後に、以下のコマンドでリカバリを完了（ポーズ解除）させます。
SELECT pg_wal_replay_resume();
—
4. 現場で震えないための知恵（注意点）
この手順をマスターしたあなたに、プロとしての極意を伝授します。
- 時刻の精度に注意： サーバーのシステム時刻（UTCかJSTか）を必ず確認してください。1時間のズレは致命的です。
- アーカイブの保存先： WALアーカイブは、データベース本体とは物理的に異なるディスクに保存してください。ディスク故障時に共倒れするのを防ぐためです。
- 訓練こそがすべて： いざという時にマニュアルを読み直している暇はありません。月に一度はステージング環境でこの「ディザスタリカバリ訓練」を行ってください。
結びに代えて
PITRは、エンジニアにとっての「タイムマシン」です。
pgAdmin 4を通じてこの仕組みを理解することは、データベースの内部構造（WAL）を知ることと同義です。
最初は難しく感じるかもしれませんが、一度成功体験を積めば、あなたのデータ管理に対する自信は劇的に向上します。万が一の時に「大丈夫、戻せますよ」と冷静に言えるエンジニア、格好いいじゃないですか。
ぜひ、安全な環境でこのシミュレーションを試してみてください。あなたのエンジニアライフが、より安心で実りあるものになることを願っています！