【Firestore】ポイントタイムリカバリ(PITR)とは何か？使い方を実例で解説

「本番データを誤って削除してしまった」「バグで意図しないデータ更新が走った」など、開発運用におけるヒヤリハットは誰にでも起こり得ます。

そんな万が一の事態からデータを救う強力な機能が、Firestoreの「ポイントインタイムリカバリ（PITR）」です。

本記事では、PITRの基本的な仕組みやメリット・デメリットをはじめ、かかるコストについても分かりやすく解説しています。

さらに、実際のコンソール画面やコマンドを使った具体的な復元手順まで実例付きで紹介しています。

ポイントタイムリカバリ(PITR)とは何か？

Firestoreのポイントインタイムリカバリ（PITR：Point-in-Time Recovery）は、過去の特定の時点のデータベースの状態を正確に復元できる強力なデータ保護機能です。

「本番データを間違えて一括削除してしまった」「バグで意図しないデータ更新が走ってしまった」というような人為的ミス（論理障害）が起きた際、「事故が起きる直前の1分前の状態に戻す」といった1秒単位のピンポイントの復旧が可能になります。

PITRの仕組み

通常のバックアップが「1日1回」などの特定タイミングの静止画（スナップショット）を保存するのに対し、PITRはデータの変更履歴を継続的に記録しています。

• 復元可能な期間（保持期間）： 過去最大7日間
• 復元精度： 1秒単位で指定可能

復元方法は、既存のデータベースに上書きするのではなく、新しいFirestoreデータベースを別途作成してそこにデータを復元します（既存の稼働中アプリに影響を与えずに復元データを検証できます）。

メリットとデメリット

メリット

データ損失を最小限に抑えられる（RPOの最小化）
1日1回のバックアップだと、最悪「24時間分」のデータが消えますが、PITRなら「数秒〜数分前」の状態に戻せるため、失われるデータがほぼゼロで済みます。

本番環境への影響がない
新しいデータベースとして復元されるため、原因究明やデータ検証を安全に行えます。

簡単な有効化
設定を「有効」にするだけで、自動的にバックアップが回り始めます。

デメリット

保持期間が短い（最大7日間）
「1ヶ月前のデータをみたい」という用途には使えません。そのため、長期保存が可能なスケジュールバックアップ（Managed Buckup）との併用が必須です。

インプレース（上書き）復元ができない
新しいデータベースに復元されるため、アプリの接続先を切り替えるか、復元先から必要なデータだけを本番に書き戻すスクリプトを組む必要があります。

ストレージコストが上がる
変更履歴を保持するため、データベースの変更頻度が高いほどコストが増加します。

かかるコスト（料金体系）

PITRを使うと、Firestoreの通常ストレージ料金とは別に、「過去7日間の変更履歴（バージョン）を維持するための料金」が上書きされる形で加算されます。

東京リージョン（または一般的なマルチリージョン）の場合、コストの目安は 1GBあたり約23〜30円 / 月 です。

もう少し具体例で紹介します。

💡 毎月の追加コストの目安（1ドル=150円換算）

• 小規模（個人アプリ・初期のサービス）
  • データ量：1 GB
  • 毎月の追加コスト：約23円〜30円 / 月
• 中規模（アクティブに運用されている一般的なサービス）
  • データ量：10 GB
  • 毎月の追加コスト：約230円〜300円 / 月
• 大規模（大規模な商用アプリや企業システム）
  • データ量：100 GB
  • 毎月の追加コスト：約2,300円〜3,000円 / 月

⚠️ 注意ポイント

この「データ量」とは、今現在のデータベース全体のサイズだけではなく、「過去7日間にどれだけ激しくデータが書き換えられたか（変更履歴の量）」も影響します。ログデータのように秒間で数千件の書き込み・更新が走り続けるコレクションがある場合、保持する履歴が増えるため、ストレージ量が膨らみやすくなります。

事故が起きた時だけかかるコスト：復元（クローン）の処理料金

普段は1円もかかりませんが、実際に「やらかしてしまって過去のデータを復元（クローン作成）した時」に1回きり発生するスポット料金です。

FirestoreのPITR復元（クローン作成）は、復元するデータのサイズ 1GB あたり一律 0.20ドル（約30円） がかかります。

（例）1回パニックになって復元ボタンを押したときの料金

• データ量 1 GB の場合：約30円 / 回
• データ量 10 GB の場合：約300円 / 回
• データ量 100 GB の場合： 約3,000円 / 回

これの非常に優れた点は、「ドキュメントの読み取り・書き込み件数による課金ではない」 という点です。

通常のFirestoreであれば、10万件のドキュメントを読み込むとそれに応じた高額な読み取り料金が発生しますが、PITRの復元は「データサイズ（GB）だけで一律計算」されるため、たとえ何百万件の細かいドキュメントが含まれていても、容量自体が少なければ数十円〜数百円のサンキュー価格で丸ごと復元できます。

無料枠はない

PITR（ポイントインタイムリカバリ）機能とその復元オペレーション（クローン作成など）には、無料枠（Free Tier）はありません。

Firestore自体には「データ保存1GBまで無料」「1日あたり50,000件の読み取り無料」といった強力な無料枠がありますが、公式ドキュメントにも明記されている通り、PITRの履歴データ保存および復元（クローン）操作はすべて無料枠の対象外となっています。

そのため、PITRを利用するためには、Google Cloud（Firebase）プロジェクトで「課金の有効化（Blazeプラン等への移行）」が必須となります。

無料枠との関係を整理すると、以下のようになります。

料金の発生パターン（おさらい）

1. 通常のデータ保存（1GBまで無料枠あり）
   • 今現在の本番データベースの容量が1GB未満なら、通常のストレージ料金は0円です。
2. PITRの履歴データ保存（無料枠なし・一律課金）
   • 有効にした瞬間から、過去7日間の変更履歴を蓄積するための料金が、1GBあたり月額約23〜30円のペースで発生します。
3. クローン（復元）操作（無料枠なし・一律課金）
   • 実際に過去のデータを新しいデータベースに復元する際、データサイズに応じて 1GBあたり一律約30円 のスポット費用が発生します。

残念ながら、PITRを「完全無料」の状態で試したりテストしたりすることはできません。

ただ、前述した通り「1GBあたり数十円」という非常に細かい従量課金のため、個人開発のアプリやデータ量が極めて少ないステージング環境であれば、有効にして数日間テストしたとしても、発生する請求は1円〜数円程度で収まります。

使い方１：PITRの有効化

Google Cloudのコンソール、または Google Cloud CLI（gcloudコマンド）から簡単に有効化できます。

コンソールの場合は、「Google Cloud ＞ Firestore ＞障害復旧」へと進みます。

「編集」をクリックします。

「ポイントタイムリカバリを有効にする」にチェックを入れ、「保存」をクリックします。

gcloud コマンドの場合

gcloud firestore databases update --database='(default)' --enable-pitr

使い方2：データの復元（リカバリ）方法

コンソールの「操作」に以下の２つのメニューがあります。

• スナップショットをエクスポート
• スナップショットのクローンを作成

スナップショットのクローンを作成（推奨：通常の復旧用）

指定した過去の時点のデータをベースに、同じプロジェクト内に「新しいFirestoreデータベース」を丸ごと複製（クローン）する機能です。

• 出力先： 新しいFirestoreデータベース

主な用途は、データの誤削除やバグからの緊急復旧です。

スナップショットをエクスポート（長期保存・外部連携用）

指定した過去の時点のデータを、Firestoreではなく「Cloud Storage（GCS）のバケット」にファイル（バイナリデータ）として書き出す機能です。

• 出力先： Cloud Storage（GCS）内のバケット
• 主な用途：
  • 「1年前の確定申告用データ」として、ファイルを別媒体（ローカルや外部ストレージ）にダウンロードして長期保管したいとき
  • BigQueryなどの分析ツールに過去のデータをインポートして、データ分析を行いたいとき
• 特徴：
  • エクスポートされたファイルはそのままではFirestoreとして使えません（中身を直接ブラウザで見ることもできません）。
  • 再びアプリで使える状態にするには、別の空のデータベースを用意して、そこへ「インポート」する手順が追加で必要になります。

復旧操作のまとめ

項目	スナップショットのクローンを作成	スナップショットをエクスポート
出力先	Firestoreデータベース	Cloud Storage (GCS) バケット
データ形式	稼働可能なデータベース	バックアップファイル（オブジェクト）
即時確認	◯（すぐコンソールで見られる）	✕（インポートしないと見られない）
主な目的	アプリの障害復旧・環境複製	データの長期保存・外部ツール連携

まとめ：どう運用すべき？

本番環境（Production）のデータベースであれば、PITRは「有効」にしておくことを強くおすすめします。 運用ベストプラクティスとしては、以下のハイブリッド構成が最も安全です。

• PITR（7日間保持）： 開発ミスのやらかしや、直近のシステムバグによるデータ破損からの「緊急脱出ボタン」として使う。
• スケジュールバックアップ<Managed Buckup>（週次・月次など）： 監査や数ヶ月前のデータ確認など、「長期的なデータ保存」として使う。

▼スケジュールバックアップ（Managed Buckup）の詳細はこちら

【Firestore】Managed Buckupとは何か？使い方を実例で解説｜料金(コスト)はいくらかかる？

Firestoreを運用する中で、「データのバックアップはどうすればいい？」「万が一のデータ消失に備えたい」と悩んでいませんか？本記事では、Firestoreの公式機能である「Managed Buckup（マネージドバックアップ）」について…

prograshi.com