Realtime Database restore verification: no built-in integrity check for restored data

Because Firebase Realtime Database does not provide built-in checksums or automated integrity validation for restored backups, verification must be handled externally. The most reliable method to confirm a successful restore is to perform a side-by-side comparison of the source and restored instances using sorted JSON exports.

Recommended Verification Workflow

To verify that the restored data matches the source without relying on manual sampling, use the Firebase CLI to export both datasets and compare their hashes. Since JSON keys can be unordered, you must sort the data before hashing to avoid false negatives.

1. Export both instances: Use the Firebase CLI to download the data from the source and the restored instance to local files.

   # Export source
   firebase database:get / --instance source-db-name -o source.json
   
   # Export restored instance
   firebase database:get / --instance restored-db-name -o restored.json

2. Normalize and Hash: Use a tool like jq to sort the keys alphabetically and pipe the output to a hashing utility (e.g., SHA-256).

   # Generate hash for source
   cat source.json | jq -S . | shasum -a 256
   
   # Generate hash for restored
   cat restored.json | jq -S . | shasum -a 256

3. Compare: If the resulting hashes are identical, the data integrity is verified.

Beyond Data: Rules and Indexes

Data integrity alone does not guarantee functional equivalence. Because restores often target new instances or projects, you must explicitly verify the following:

• Security Rules: Export the database.rules.json from both environments and run a diff. Mismatched rules can lead to unauthorized access or application crashes.
• Query Indexes: Verify that .indexOn definitions are present in the restored rules. If indexes are missing, queries that worked on the source will fail or perform poorly on the restored instance.

Likely Explanations and Constraints

The lack of a built-in checksum is likely due to the NoSQL nature of the database, where the "backup" is essentially a JSON snapshot. If you are dealing with datasets too large for a single firebase database:get command (which may trigger timeouts), you will need to paginate your exports by targeting specific sub-nodes (e.g., /users, /orders) and hashing them individually.

One diagnostic detail needed: Are you restoring to a different Google Cloud project or simply a different database instance within the same project? If it is a different project, you must also verify that any associated Cloud Functions or IAM roles have been replicated, as these are not part of the database backup.