Chapter 22 · Backups, Point-in-Time Recovery, Restore, and Disaster Recovery
Export / Import vs Managed Backups / PITR: Different Purposes, RPO / RTO, and Operational Workflows
Compare managed export/import, scheduled backups, and PITR by consistency point, index/config payload, partial-application behavior, billing, and operational purpose.
1. AtlasMart problem: “we exported it, so we have a backup”
A weekly script runs gcloud firestore export to
Cloud Storage and the team labels the result “our backup.” After
a corruption incident, they discover that export semantics,
indexes, restore behavior, and operational permissions differ
from scheduled backups and PITR. The problem is not that export
is useless; the problem is assigning it recovery guarantees it
does not provide.
- Compare managed export/import, scheduled backup restore, PITR clone, and stale-read repair by consistency point and payload.
- Explain why an export is not an exact database snapshot taken at export start.
- Explain why exports do not carry index definitions while managed backups include index configurations.
- Identify import side effects: overwrites, unaffected documents, listener updates, and no Cloud Functions triggers.
- Choose a mechanism based on recovery objective rather than naming familiarity.
Use the Emulator Suite, a Firebase demo project, or an isolated test project for destructive, security-sensitive, billing-sensitive, migration, backup/restore, or write-heavy exercises unless the lesson explicitly marks managed verification as required. Treat shown output as expected evidence unless it is explicitly identified as captured output, and re-check current Firebase/Google Cloud edition, mode, quota, pricing, and security documentation before production execution.
AtlasMart keeps the course-wide identity
demo-atlasmart-firestore. Mandatory work is local
and no-cost: Node.js 22+, Firebase CLI 15.30.0,
Firebase Admin Node SDK 14.4.0, Firestore
emulator 127.0.0.1:8080, Auth emulator
127.0.0.1:9099, and Emulator UI
127.0.0.1:4000. The normal application database
is Standard-edition Native mode, database
(default). A second emulator project namespace,
demo-atlasmart-recovery, acts as the isolated
restore target. Managed scheduled backups, PITR, clone,
managed export/import, backup storage, and managed restores
require a real billing-enabled project and are therefore
optional production-verification exercises, not mandatory lab
prerequisites.
A scheduled backup is a consistent point-in-time database copy. A managed export is a data-movement operation whose output may include changes made while the export is running. A PITR clone uses retained historical versions to create a new database at a selected minute. Treat each mechanism according to its documented semantics.
2. Side-by-side recovery contract
| Dimension | Scheduled backup | PITR clone/read | Managed export/import |
|---|---|---|---|
| Consistency point | Consistent point-in-time backup | Selected historical timestamp | Export is not guaranteed to be exact at export start |
| Retention | Configured up to 14 weeks | Up to 7 days when PITR enabled | Cloud Storage lifecycle/retention is separate |
| Indexes | Backup contains index configurations | Clone includes data + indexes | Export files do not include index definitions; import uses target current index definitions |
| TTL policy | Not included | Treat as database configuration that must be verified/reapplied on new target | Not conveyed by data export |
| Target | Restore to new database (or destructive same-name workflow) | Clone to new database or selective live repair | Import into chosen database/project |
| Primary use | Recovery points | Fine-grained historical recovery | Data movement/archive/offline processing |
3. Managed export is a long-running data operation
Firestore’s managed export service can export the entire database or selected collection groups to Cloud Storage. It requires billing. Export incurs one read operation per exported document, and those export reads are not necessarily visible in the normal console usage section. Because the export is not an exact database snapshot at operation start, a high-write application can produce an output that spans changes occurring during the operation.
Exporting a collection group does not automatically include
unrelated descendant collection groups. If AtlasMart exports
profiles, a nested
orders subcollection group must be included
explicitly when that data is required.
4. Import semantics can surprise recovery operators
- If a document ID already exists, import overwrites that document.
- Documents in the target that are not affected by the import remain in place; import is not “replace the whole database.”
- Indexes are updated according to the target database’s current index definitions.
- Managed import does not trigger Cloud Functions, but snapshot listeners can receive changes related to the import.
- Cancelling an import does not roll back writes already applied. A cancelled import can leave a partially updated target.
In the local drill, simulate a partially applied import and prove your validation rejects the target until counts, hashes, and business-query regression pass. The repair is not “resume traffic because the import command exited.”
5. Mandatory local lab: compare three deterministic recovery artifacts
Create one canonical source dataset and represent three recovery
choices as manifests:
backup-manifest.json (point-in-time, data +
indexes), pitr-manifest.json (historical minute +
selected subset/full clone), and
export-manifest.json (data-only export with target
index manifest supplied separately). The goal is to make the
missing configuration visible.
import fs from "node:fs/promises";const backup = JSON.parse(await fs.readFile("fixtures/backup-manifest.json", "utf8"));const pitr = JSON.parse(await fs.readFile("fixtures/pitr-manifest.json", "utf8"));const exp = JSON.parse(await fs.readFile("fixtures/export-manifest.json", "utf8"));for (const [name, m] of Object.entries({backup, pitr, export: exp})) { console.log(name, { recoveryPoint: m.recoveryPoint, dataHash: m.dataHash, includesIndexes: !!m.includesIndexes, includesTtlPolicy: !!m.includesTtlPolicy, exactPointInTime: !!m.exactPointInTime });}if (exp.includesIndexes) throw new Error("fixture bug: managed export must not be modeled as carrying index definitions");if (backup.includesTtlPolicy) throw new Error("fixture bug: backup must not be modeled as carrying TTL policies");| Evidence | Backup fixture | PITR fixture | Export fixture |
|---|---|---|---|
| Data hash | Required | Required | Required |
| Index config | Included in modeled backup | Clone includes indexes | Separate target config |
| TTL config | Separate | Separate verification | Separate |
| Recovery timestamp | Backup timestamp | Selected historical minute | Export operation evidence |
| Partial-application risk | Restore target unavailable until complete | Selective repair depends on your writes | Import cancellation can leave applied writes |
6. Optional managed export/import commands
# Billing-enabled project and Cloud Storage bucket required.gcloud firestore export gs://YOUR_BUCKET/atlasmart-drill \ --database='(default)'# PITR export uses a whole-minute snapshot-time within the valid window.gcloud firestore export gs://YOUR_BUCKET/atlasmart-pitr \ --database='(default)' \ --snapshot-time='2026-09-17T01:41:00Z'# Import into an isolated database; validate before traffic.gcloud firestore import gs://YOUR_BUCKET/atlasmart-drill/EXPORT_PREFIX/ \ --database='recovery-drill' 7. Decision framework
| Requirement | Prefer | Why |
|---|---|---|
| Periodic database recovery point | Scheduled backup | Consistent managed recovery artifact, data + index config |
| Undo a localized recent mistake | PITR stale read | Small blast radius and preservation of unrelated current state |
| Validate a whole historical state in isolation | PITR clone | New database at a selected historical timestamp |
| Archive beyond backup retention | PITR/current export to Cloud Storage | Storage retention can outlive 14-week backup limit |
| Move data between projects | Export/import or supported migration tooling | Explicit data movement workflow |
| Recover app runtime/config | Versioned infrastructure + deployment artifacts | Database recovery does not reconstruct the whole application |
Verification checklist and cleanup
- Recovery mechanism is named precisely in the runbook.
- Export is not documented as an exact start-time snapshot.
- Index definitions/configuration source is present for any export/import recovery.
- Import validation accounts for overwrites and unaffected target documents.
- Any cancelled/failed import is treated as potentially partial until proven otherwise.
- Billing/storage permissions are tested only in isolated optional environments.
Bridge to Lesson 4
Mechanism selection solves only part of disaster recovery. Lesson 4 examines a common architecture mistake: treating multi-region replication as if it protected against logical corruption, credentials misuse, or operator deletion.
Knowledge check
- Is a managed export an exact snapshot taken at export start?
- Do export files contain Firestore index definitions?
- Does importing delete unrelated target documents?
- Do managed imports trigger Cloud Functions?
- What happens when an import is cancelled?
Review the answers
1. No. The export may include changes made while it is running.
2. No. Imports use the target database’s current index definitions.
3. No. Documents not affected by the import remain.
4. No, while snapshot listeners can receive related updates.
5. Applied updates are not rolled back automatically; the target can be partial and must be validated/repaired.
Summary and next step
This lesson established the working contract for Export/Import vs Managed Backups/PITR: Different Purposes, RPO/RTO, and Operational Workflows. Keep its edition/mode assumptions, trust boundary, verification evidence, and operational constraints explicit when reusing the pattern.
Next, continue to Multi-Region Location Does Not Replace Backup: Failure Modes, Logical Corruption, and Operator Mistakes.
Authoritative references
- Firebase: Back up and restore data — scheduled backup semantics, retention, roles, restore behavior, and post-restore checks.
- Firebase: Point-in-time recovery (PITR) — historical-version window, read granularity, clone/export recovery paths, and billing.
- Firebase: Manage databases — clone semantics, destination identity, location, encryption, and permissions.
- Firebase: Export and import data — managed export/import behavior, billing, index handling, and operation caveats.
- Firebase: Disaster recovery planning — availability versus recoverability and recovery mechanism selection.