Back up and restore Firestore collections

Back up a collection or a database

1. In the sidebar, right-click a collection and choose Back up collection…. To back up every collection in a database, right-click the database (or the project, for its default database) and choose Back up every collection….
2. Firetool reads every document and its subcollections, and shows how many documents it has read so far. Cancel stops it; nothing is saved.
3. When reading is done, a save dialog opens. Choose the folder; the file name is suggested for you, for example my-project_default_orders_backup_2026-10-01-09-30.json (project, database, collection, then the date and time in UTC).
4. When it's saved, choose Show in folder in the message to find the file.

The backup is also recorded in the audit log, with the number of documents and where the file went. Because a backup is a kind of export, it follows your policy's export switch: if exports are turned off for a project, its backups are too.

The whole backup is built in memory before it's saved. A very large collection needs a lot of memory; for those, back up one collection at a time.

What's in the file

A backup is one plain JSON file:

{
  "format": "firetool-backup",
  "version": 1,
  "project": "my-project",
  "database": "(default)",
  "root": "orders",
  "createdAt": "2026-10-01T09:30:12.345Z",
  "count": 2,
  "documents": [
    { "path": "orders/A1", "fields": { "total": { "integerValue": "5400" } } },
    { "path": "orders/A1/items/1", "fields": { "sku": { "stringValue": "K-7" } } }
  ]
}

• root is the collection you backed up, or empty for a whole-database backup.
• count is the number of documents.
• Each document has its full path and its fields exactly as Firestore stores them, so every type comes back unchanged: 64-bit integers, timestamps to the microsecond, NaN, bytes, references, geopoints, maps and arrays.
• Subcollections are included at any depth, each document with its own path. That includes subcollections under a parent document that doesn't exist itself (the ones the Firebase console shows in italics). The empty parent isn't saved, as there's nothing in it.

Backups made by earlier versions, when the app was called Firestore Studio, still restore.

What isn't in a backup

Only documents and their fields. A backup doesn't contain:

• Firebase Authentication users.
• Composite indexes or security rules.
• When each document was created or last changed. Restored documents get a new update time.

Restore a backup

1. Right-click the database you want to restore into (or its project) and choose Restore a backup…. This can be the database you backed up, or another database or project. You can also open a collection and choose Import with a backup file: Firetool recognises it and opens the same restore dialog for that tab's database.
2. Choose the backup file. The dialog shows how many documents it holds, where they came from, which collection, and when it was made.
3. Under If a document already exists, choose Replace it with the backed-up version or Keep it, skip that document.
4. Choose Restore. With Replace, Firetool asks you to confirm first, because the current versions can't be put back afterwards unless your policy keeps copies of every change. If you might need them, cancel and back up the target first.

Documents go back to the same paths they had, with their subcollections. You choose the project and database; the paths inside come from the file. If the target is another project or database, references that pointed into the backed-up database are pointed at the same paths in the target.

Firetool writes in batches of 500 and shows how many are restored and skipped. Cancel stops after the current batch. If it stops or some documents fail, the button reads Resume, which continues with only the documents that didn't make it.

Check a backup before you need it

• Open the file in any text editor: count should match the number of documents you expect.
• Choose Restore a backup… and pick the file, then read the summary and choose Cancel. Nothing is written until you choose Restore. A damaged file is refused with the number of the first bad document; a file from a newer Firetool asks you to update.
• For a full test, restore it into a separate database or test project and compare.

Production, read-only and Pro

• Backups and restores need Firetool Pro.
• Restoring into a database marked read-only is refused before anything is written.
• If the target is marked production, you type its project ID before the restore writes.
• Every restore write passes the same checks as any change and is recorded in the audit log.

Restore a single change from the audit log

For a mistake rather than a disaster, you may not need a backup file. Firetool keeps copies of documents before some changes:

1. Choose Tools → Audit log (Ctrl+Shift+L) and click the entry for the change.
2. If Firetool saved the documents as they were, the entry says so and offers Restore N documents. Choose it and confirm.

Limits:

• By default copies are kept for deleted documents, single-document edits and bulk field changes. Imports, copies, restores and script updates are only covered if your policy keeps copies of Everything that changes; a policy can also turn copies off.
• Restoring writes the old versions back over any later changes. Documents that didn't exist before the change aren't removed.
• The account that made the change must still be connected.
• Authentication users can't be restored this way.

Questions

Related

• Firestore backup: what a Firetool backup keeps and how restore works.
• Copy collections: copy or move collections between projects directly.
• Scheduled exports: CSV or JSON exports on a schedule.
• Roles and production safety: read-only and production marks, and the audit log.