Solved: Firestore Backup Stuck in Creating State

jaaywags · 11-08-2023 02:59 PM

I created a firestore backup job following this guide. I have been waiting for about 5 hours and every time I check the status of the job, it says the STATE is CREATING. I feel like it should not take this long. It is a large database but not that large.

gcloud alpha firestore backups list --format="table(name, database, state)"
NAME                        DATABASE                                    STATE
projects/<project-id>/...   projects/<project-id>/databases/(default)   CREATING

Should I delete the backup schedule? I really don't want to mess anything up in this project.

jaaywags

Finally, the state says READY. The entire thing probably took 6 or 7 hours.

I think I will try point in time recovery instead. IDK if there is a benefit to using one over the other.

View solution in original post

ms4446

I'm glad to hear that your Firestore backup job is now ready. The time it took for the job to switch to the 'READY' state might indicate performance considerations, which are worth monitoring in your project or Firestore service.

When it comes to choosing between point-in-time recovery (PITR) and scheduled backups, each serves its purpose and offers different levels of data protection:

Scheduled Backups create snapshots of your entire Firestore database at scheduled intervals. These backups can be retained indefinitely, allowing you to restore your database to the exact state it was in at the time of any given backup. This method is ideal for recovery from catastrophic events such as hardware failures, natural disasters, or significant human errors.
Point-in-Time Recovery (PITR), on the other hand, provides the ability to restore your database to any state within the last 30 days. This includes the entire database or specific documents and collections, offering a more granular recovery option. PITR is particularly useful for addressing accidental deletions, application bugs, or data corruptions that are identified within a month.

Here's a table summarizing the key differences between scheduled backups and PITR:

Feature	Scheduled Backups	PITR
Protection Scope	Entire database	Entire database or specific elements
Retention Period	Indefinite	Last 30 days
Recovery Method	Restore the database to the state at the time of backup	Restore to any point within the retention window
Use Cases	Recovery from catastrophic events, long-term archival	Accidental deletions, bugs, and corruptions, frequent and granular recovery needs

The choice between scheduled backups and PITR should be based on your specific data protection requirements. If you need long-term archival and the ability to restore from historical points, scheduled backups are the way to go. If you require the flexibility to recover from more recent issues with the ability to pinpoint the exact time for recovery, PITR would be more suitable.

For the most comprehensive protection, a combination of both scheduled backups for long-term retention and PITR for recent, granular recovery could be the best strategy. This dual approach ensures that you're prepared for a wide range of data loss and corruption scenarios.