Stay organized with collections
Save and categorize content based on your preferences.
Firestore in Datastore mode point-in-time recovery (PITR) provides protection against
accidental deletion or writes. PITR maintains versions of your
entities from past timestamps. For example, in the case of a developer
pushing the incorrect data, accidental deletes or writes, PITR can recover the
data to a point in time in the past (up to a maximum of 7 days) seamlessly.
For any live database that follows Best practices, use
of PITR doesn't affect the performance of reads or writes.
PITR window
After you enable PITR, Datastore mode starts retaining PITR data. PITR data is
retained for 7 days in the PITR window.
You can read data for a timestamp based on when PITR was enabled:
PITR enablement status
Earliest PITR data available
Disabled
1 hour before the time of read request
enabled within 7 days
1 hour before PITR was enabled
enabled more than 7 days ago
7 days before the time of read request
A single version per minute is retained in the PITR window. You can read documents at minute
granularity using a whole minute timestamp. Only one version of a document is
retained in case of multiple writes. For example, if a document had multiple
writes ranging from v1, v2, ... vk between 2023-05-30 09:00:00AM (exclusive)
and 2023-05-30 09:01:00AM (inclusive) timestamp, a read request at timestamp
2023-05-30 09:01:00AM returns the vk version of the document.
You can read from the data created during the PITR
window. The data is stored at a minute granularity and you can recover data
at the same granularity. Datastore mode PITR feature is disabled by default.
The earliestVersionTime field of your database specifies the
earliest permissible read time for your data.
Regardless of whether PITR is enabled or not, you can read (but not export) documents at any microsecond-granularity timestamp within the past hour, but not before the earliestVersionTime.
Ways to recover data
There are two ways to recover data:
To recover a portion of the database, perform a stale read
specifying a query-condition or using direct key lookup along with a
timestamp in the past, and then write the results back into the live
database. This is typically used for surgical operations on a live database.
For example, if you accidentally delete a particular entity or
incorrectly update a subset of data, you can recover it with this method.
For instructions, see recovering a portion of your database.
To recover the entire database, use one of the following options:
Clone the database
to create a copy of the database at a specific timestamp.
Export the database and specify
a timestamp in the past and then import it to a new database. The PITR
export operation supports all filters, including export of all entities and
export of specific kinds and namespaces.
You can clone or export PITR data where the timestamp
is a whole minute timestamp within the past seven days, but not earlier than
the earliestVersionTime.
Pricing
Consider the following pricing information before you enable PITR for your database:
Storage: Datastore mode measures the database size daily. Over the
period of a month, these sample points are averaged to calculate the
database storage size. This average value is multiplied by the unit price of
PITR (GB-month). See the storage pricing for more information.
PITR storage doesn't have a free tier and you must have billing enabled if you
want to use PITR.
Compute billing: Any queries that you make during the PITR window of 7 days,
either through stale reads or exports, incur read operation costs
based on the number of documents read. See pricing for more
information.
Minimum billing: You may be charged up to 1 day of PITR storage cost even if
you disable PITR within a day after enablement.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-28 UTC."],[[["\u003cp\u003eFirestore in Datastore mode's point-in-time recovery (PITR) feature protects against accidental data deletion or incorrect writes by retaining versions of entities for up to 7 days, allowing for seamless data recovery.\u003c/p\u003e\n"],["\u003cp\u003eEnabling PITR does not affect the performance of reads or writes for live databases that adhere to best practices.\u003c/p\u003e\n"],["\u003cp\u003ePITR data is retained for 7 days, and data can be read at minute granularity within this window, where the availability of data depends on when PITR was enabled, with the earliest available data ranging from 1 hour before a read request to 7 days prior.\u003c/p\u003e\n"],["\u003cp\u003eData can be recovered either by performing stale reads on a portion of the database and writing it back or by exporting the entire database to a specific point in time and importing it into a new database.\u003c/p\u003e\n"],["\u003cp\u003eUsing PITR incurs storage and compute costs, with storage measured daily and averaged monthly, and read operation costs for any queries within the 7-day PITR window, additionally there is a potential charge for up to 1 day of storage even if the feature is turned off quickly.\u003c/p\u003e\n"]]],[],null,["# Point-in-time recovery (PITR) overview\n\nFirestore in Datastore mode point-in-time recovery (PITR) provides protection against\naccidental deletion or writes. PITR maintains versions of your\nentities from past timestamps. For example, in the case of a developer\npushing the incorrect data, accidental deletes or writes, PITR can recover the\ndata to a point in time in the past (up to a maximum of 7 days) seamlessly.\n\nFor any live database that follows [Best practices](./best-practices), use\nof PITR doesn't affect the performance of reads or writes.\n\nPITR window\n-----------\n\nAfter you enable PITR, Datastore mode starts retaining PITR data. PITR data is\nretained for 7 days in the PITR window.\n\nYou can read data for a timestamp based on when PITR was enabled:\n\n| **Note:** You can't start reading from seven days in the past immediately after you enable PITR.\n\nA single version per minute is retained in the PITR window. You can read documents at minute\ngranularity using a whole minute timestamp. Only one version of a document is\nretained in case of multiple writes. For example, if a document had multiple\nwrites ranging from `v1, v2, ... vk` between `2023-05-30 09:00:00AM` (exclusive)\nand `2023-05-30 09:01:00AM` (inclusive) timestamp, a read request at timestamp\n`2023-05-30 09:01:00AM` returns the `vk` version of the document.\n\nYou can read from the data created during the PITR\nwindow. The data is stored at a minute granularity and you can recover data\nat the same granularity. Datastore mode PITR feature is disabled by default.\n\nThe [earliestVersionTime](/firestore/docs/reference/rest/v1/projects.databases#resource:-database) field of your database specifies the\nearliest permissible read time for your data.\n\nRegardless of whether PITR is enabled or not, you can read (but not export) documents at any microsecond-granularity timestamp within the past hour, but not before the earliestVersionTime.\n\nWays to recover data\n--------------------\n\nThere are two ways to recover data:\n\n- To **recover a portion of the database** , perform a [stale read](/firestore/docs/understand-reads-writes-scale#stale_reads)\n specifying a query-condition or using direct key lookup along with a\n timestamp in the past, and then write the results back into the live\n database. This is typically used for surgical operations on a live database.\n For example, if you accidentally delete a particular entity or\n incorrectly update a subset of data, you can recover it with this method.\n For instructions, see [recovering a portion of your database](/datastore/docs/use-pitr#read-pitr).\n\n- To **recover the entire database** , [export](/datastore/docs/use-pitr#export-import) the database specifying\n a timestamp in the past and then import it to a new database. The PITR\n export operation supports all filters, including export of all entities\n and export of specific kinds or namespaces. Note that exporting a database could\n take several hours. You can export PITR data where the timestamp is a whole\n minute timestamp within the past seven days, but not earlier than the\n earliestVersionTime.\n\nPricing\n-------\n\nConsider the following pricing information before you enable PITR for your database:\n\n- Storage: Datastore mode measures the database size daily. Over the\n period of a month, these sample points are averaged to calculate the\n database storage size. This average value is multiplied by the unit price of\n PITR (GB-month). See the [storage pricing](/firestore/pricing) for more information.\n\n PITR storage doesn't have a free tier and you must have billing enabled if you\n want to use PITR.\n- Compute billing: Any queries that you make during the PITR window of 7 days,\n either through stale reads or exports, incur read operation costs\n based on the number of documents read. See [pricing](/firestore/pricing) for more\n information.\n\n- Minimum billing: You may be charged up to 1 day of PITR storage cost even if\n you disable PITR within a day after enablement.\n\nWhat's next\n-----------\n\n- Learn more about how to [recover data with PITR](/datastore/docs/use-pitr)."]]
