【Firebase】Firestoreのバックアップを取る方法|Managed BackupsとManaged Exportの違い。どちらを使うべきか?

firebase-prograshi(プロぐらし)-kv Firebase
記事内に広告が含まれていることがあります。

Firestoreのデータ保護機能は日々進化しています。定期的なバックアップを自動化できる「Managed Backups」の登場により、従来の「Managed Export」を使った独自実装(Cloud FunctionsやCloud Schedulerの組み合わせ)とどちらを選ぶべきか、運用の最適化を迫られている開発者も少なくありません。

本記事では、これら2つのバックアップ機能の仕組みの違いを掘り下げ、「どちらがベストか」の判断基準までを紹介しています。


Firestoreの2つの主なバックアップ方法

Firestoreのバックアップとデータ移行を検討する際、主な方法は2つあります。

Firestoreの2つの主なバックアップ方法
  1. Managed Backups(管理型バックアップ)
  2. Managed Export(管理型エクスポート)

「Managed Backups(スケジュールバックアップ)」と「Managed Export/Import(エクスポート/インポート)」のどちらを選ぶべきかは、本番運用の安全性やコストに直結する非常に重要なポイントです。

それぞれの機能の根本的な違い、メリット・デメリット、そして「どちらを選ぶべきか」の判断基準を詳しく解説します。


Managed Backups と Managed Export の決定的な違い

2つの最大の違いは、「DR(災害復旧・誤操作対策)」のためのシステム内蔵バックアップか、それとも「データの持ち出し・移行」のためのファイル出力かという点にあります。

項目Managed Backups(スケジュールバックアップ)Managed Export(エクスポート)
主な目的データ破損・誤削除からの迅速な復旧(DR)別環境へのデータ移行、BigQuery等での分析
保存先Firestore内部(ユーザーはファイルに触れない)ユーザーが指定した Cloud Storage (GCS)
データの一貫性完全な特定時点(Point-in-Time)の一貫性結果整合性(エクスポート中に更新があるとズレる)
課金対象バックアップの「ストレージ(GCS)容量」のみドキュメントの**「読み取り数(Read)」** + GCS容量
リストア先同一プロジェクト内の「新規データベース」既存DBへの上書き/
別プロジェクトへのインポート
保存期間最大14週間(自動削除)無制限(GCSで設定したライフサイクルルールによる)


Managed Backups(管理型バックアップ)とは何か?

Firestoreがネイティブで提供している定期バックアップ機能です。

データベースそのものの状態を、Googleのインフラ側が自動で「スナップショット(ある一瞬のクローン)」として丸ごと保存してくれる機能です。

日次または週次での定期実行をコンソールやgcloudコマンドから簡単にスケジュールできます。

メリット

  • コストが圧倒的に安い(データ量が多い場合)
    ドキュメントの読み取りが発生しないため、数百万・数千万件のデータがあっても、純粋なデータ容量のストレージ料金しかかかりません。
  • インデックス情報も含む
    データベースの状態をそのまま丸ごと保存します。
  • 本番パフォーマンスへの影響ゼロ
    バックアップ処理によってDBの読み書きが重くなることがありません。


デメリット

  • 既存DBへの上書き復旧ができない
    リストア時は必ず「新しいデータベース(同一プロジェクト内)」として復元されます。
    アプリ側の接続先を切り替えるか、データを移行する必要があります
  • 別プロジェクトへの移動が不可
    バックアップデータをローカルにダウンロードしたり、別プロジェクトに持っていったりはできません


特徴まとめ

Managed Backupsは設定がとても簡単で、現在使っているデータベースの中身を完全に復元でき、しかも激安のバックアップシステムです。

ただし、その簡易さゆえ、用途は現在使用しているデータベースのみに限定されます。つまり、復元時の自由度は低いです。

Managed Buckupの保存期間の詳細

バックアップデータの保存期間は、最小1日間 〜 最大14週間(98日間)の間で、1日単位で自由に設定できます

保存期間を過ぎたバックアップは、Firestoreのシステムによって自動的に削除されるため、ライフサイクル管理の手間がかかりません。


Managed Export(管理型エクスポート)とは何か?

指定したコレクション、またはデータベース全体をファイル(LevelDBログ形式)としてCloud Storageに書き出す機能です。

エクスポート実行中に動き続けているデータがある場合、厳密に「ある一瞬の静止画」としてのバックアップにはなりません。

メリット

特定の「コレクショングループ」だけを指定してエクスポート可能といった、高い柔軟性があります。

本番環境のデータをステージング(検証)環境の別プロジェクトにインポートして再現する、といった別環境への移行ができます。

エクスポートしたデータをそのままBigQueryにロードして分析に使えます。


デメリット

大量データ時のコストが超高額になります

具体的には、エクスポート時に「全ドキュメントの読み取り(1ドキュメント=1Read)」インポート時に「全ドキュメントの書き込み(1ドキュメント=1Write)」のオペレーション料金が容赦なく発生します。


歴史を知ろう|なぜManaged Buckupが登場したのか?

Managed Exportは以前から存在し、Managed Backupsはその不便さを解消するために後から登場したFirestore完結型の標準機能というのが歴史の背景にあります。

従来のManaged Exportで「自動バックアップ(定期実行)」を組もうとすると、開発者が複数のサービスを組み合わせる必要がありました



従来のバックアップ手法 ー Managed Exportの手間

「データをエクスポートする機能」自体は、Firestoreの標準APIとして用意されています。しかし、これ単体には「定期的に自動で実行する」というスケジュール機能がありません。

Managed Exportとは、exportDocuments APIというFirestoreの機能です。これが担うのは、FirestoreのデータをStorage(GCS)に保存するところまでです。

そのため、実務で使い物になる「自動バックアップシステム」として機能させるには、以下のように複数のサービスを連携させる必要がありました。

  1. Firestore(exportDocuments API): データをバケットに出力する命令を出す
  2. Cloud Storage: 出力されたバックアップデータ(メタデータとデータファイル)を保存する
  3. Cloud Scheduler: 「毎日夜中3時に実行する」というタイマーの役割
  4. Cloud Functions / Pub/Sub: タイマーの合図を受け取り、FirestoreのAPIを実行する仲介役

ここでいう「Managed(管理された)」とは、エクスポート処理中の分散処理やデータの一貫性をGoogle側が管理(Manage)してくれるという意味です。「定期実行の手間まで全自動で管理してくれる」という意味ではありません。


新しい標準機能 ー Managed Backupsの手軽さ

こうした「わざわざ他のサービスを組み合わせないと自動化できない」という従来の不便さを解消するために登場したのが、Managed Backupsです。

Firestore完結型の標準機能となっています。

  1. Cloud SchedulerやCloud Functionsなどを自前で用意する必要はい一切なし。
  2. Firestoreの設定(gcloud コマンドなど)で「毎日バックアップを取る」「保存期間は14日間」とポリシーを決めるだけで、Firestoreの内部で自動的にすべてが完結する。
  3. データも専用の領域に保存されるため、自前のCloud Storageバケットを用意・管理する必要すらない。


【結論】どちらを使うべきか?

「Managed Backups(スケジュールバックアップ)」と「Managed Export/Import(エクスポート/インポート)」はどちらか一方ではなく、用途によって使い分けるのが現在のベストプラクティスとされています。


「Managed Backups」を使うべきケース

  • 本番環境の「万が一の備え(データ復旧用)」として定期バックアップしたいとき
  • データ件数が多く、毎日エクスポートを回すとRead数による課金が跳ね上がるシステム

判断の目安: 通常の運用保守、ヒューマンエラーによるデータ誤削除対策、システムの障害対策であれば、迷わず Managed Backups を有効(日次等)にしてください。


「Managed Export」を使うべきケース

  • 本番環境のデータを、ステージング環境(別プロジェクト)にコピーしたいとき
  • FirestoreのデータをBigQueryにインポートして、SQLで詳細なデータ分析を行いたいとき
  • システムの仕様変更に伴い、特定のコレクションだけを退避させておきたいとき

判断の目安: 「データの移行・複製」や「外部ツールでの分析」など、データを動かす明確な目的があるときだけ Managed Export を使用します。


運用のベストプラクティス

最もおすすめなのは以下の組み合わせです。

おすすめのバックアップ構成
  1. 普段のセーフティネットとして Managed Backups を自動運用する。
  2. 開発・検証でデータが必要になったタイミングや、数ヶ月に1度のアーカイブ目的としてのみ Managed Export を手動(または限定的)に実行する」というハイブリッドなアプローチです。

これにより、コストを最小限に抑えつつ、安全なインフラを構築できます。


Managed Backups の有効化(gcloudの例)

現在はGoogle Cloud Consoleの「データベース」設定、または以下のgcloudコマンドで簡単にスケジュールを組めます。

# 日次バックアップ(保存期間7日間)のスケジュールを作成
gcloud alpha firestore backups schedules create \
    --database='(default)' \
    --retention=7d \
    --recurrence=daily


タイトルとURLをコピーしました