How to Restore Your FlutterFlow Firestore Database from a Backup

Before attempting any restore, answer three questions: (1) What data is missing or corrupted? A specific collection, a specific document, or the entire database? (2) When did it last have correct data? Today? Last week? (3) What backup method was in place? Cloud Storage export, PITR, or JSON/custom backup? For accidental deletion of a few documents in the last 7 days with PITR enabled: use method 3 (PITR). For a mass delete or corruption event where you know the timestamp: use method 3 (PITR) or method 2 (full import) to a test project first. For a specific collection that was corrupted while other data is fine: use method 4 (selective restore via temporary project). Never start a restore on production without first doing a dry run on a test Firebase project.

If you have a Cloud Storage export created via Firebase Console → Firestore → Import/Export or via a Cloud Function using admin.firestore().exportDocuments(), restore it with: firebase firestore:import gs://your-backup-bucket/backup-folder (using Firebase CLI after code export from FlutterFlow, or via gcloud CLI). Alternatively, in Google Cloud Console → Firestore → Import/Export → Import, enter the gs:// path of the export. WARNING: this operation overwrites ALL existing Firestore data. Any documents written after the backup was created will be permanently deleted. Always test on a dev Firebase project first by importing there and verifying the data looks correct before restoring production.

PITR is the easiest restore method if your Firestore is in Native mode and PITR is enabled (Firebase Console → Firestore → Settings → Point-in-time recovery → Enable). PITR maintains a 7-day history of your database state. To restore: In Firebase Console → Firestore → Recovery, click Restore database. Select a timestamp (e.g., 2 hours before the accidental deletion). Choose a target: either restore to the current database (overwrites current data) or create a new database at that point-in-time. The 'create new database' option is safer — it creates a parallel database you can inspect before deciding to switch traffic to it. PITR restores can take 1-4 hours depending on database size.

When only part of your database needs restoring (e.g., the orders collection was accidentally cleared but users and products are fine), avoid a full restore that would also roll back recent legitimate changes to other collections. Instead: (1) Import the backup to a new temporary Firebase project (create one free in Firebase Console). (2) In the temporary project, run a Cloud Function that reads the specific collection and writes each document to your production project using the Firebase Admin SDK with admin.initializeApp(productionCredentials). (3) Query Firestore in the temp project: await sourceDb.collection('orders').get(). (4) For each document, write to production: await productionDb.collection('orders').doc(doc.id).set(doc.data()). This overwrites only the orders collection while leaving all others untouched.

1// Cloud Function: restoreCollectionFromBackup
2// Run in the TEMPORARY Firebase project pointing at production as destination
3const admin = require('firebase-admin');
4const sourceDb = admin.firestore(); // temp project DB (backup data)
5
6// productionDb uses service account of the PRODUCTION project
7const { initializeApp, cert } = require('firebase-admin/app');
8const prodApp = initializeApp({ credential: cert(require('./prod-service-account.json')) }, 'production');
9const productionDb = require('firebase-admin/firestore').getFirestore(prodApp);
10
11async function restoreCollection(collectionName) {
12  const snapshot = await sourceDb.collection(collectionName).get();
13  const batch = productionDb.batch();
14  let count = 0;
15  for (const doc of snapshot.docs) {
16    batch.set(productionDb.collection(collectionName).doc(doc.id), doc.data());
17    count++;
18    if (count % 500 === 0) await batch.commit();
19  }
20  await batch.commit();
21  console.log(`Restored ${snapshot.docs.length} documents to ${collectionName}`);
22}

After any restore operation, run a verification checklist before your FlutterFlow app starts using the restored data: (1) Check document counts match expected values in Firestore Console → collection → document count. (2) Open 5-10 randomly selected documents and verify their fields look correct — especially recently created records that should exist. (3) Test read queries that your FlutterFlow Backend Queries use — verify they return expected data. (4) Test write operations — add a test document, verify it appears, then delete it. (5) Check Firestore Security Rules still work — run the Rules Playground for your key auth scenarios. (6) If you restored to a new database, update the Firestore database ID in your FlutterFlow project (Settings → Firebase → Database ID) and redeploy. Allow 30-60 minutes of observation before considering the restore complete.