Verifying Grafana Dashboard Restorations: Is Checksum or Manual Diff Sufficient?

Goal

Restore dashboards and related objects from a Grafana backup while ensuring that every restored component—dashboards, data sources, alert rules, and annotations—matches the original state.

Constraints & Uncertainty

• Grafana 9+ offers a CLI backup that bundles dashboards, data sources, and alert rules, but the documentation does not state whether the archive includes a version checksum or any integrity metadata.
• Alert rules may not migrate automatically if the target instance uses a different alerting engine or a newer Grafana version.
• Data source credentials are encrypted; restoring without the correct secret key can silently fail, leading to incomplete dashboards.
• Direct JSON imports may overwrite existing dashboards with the same UID unless a dry‑run or UID conflict check is performed.

Unresolved Decision

Should Grafana’s backup/restore workflow embed a verification step—such as a checksum of each dashboard JSON or a metadata tag indicating the source Grafana version—or should administrators rely solely on manual comparison after restoration?

Specific Questions

1. Does the current grafana‑backup CLI generate a checksum for each dashboard or alert rule included in the archive?
2. What is the recommended method to confirm that alert rules survive a restore when the target Grafana instance has a different alerting engine?
3. Which metadata fields should be added to a backup archive to guarantee compatibility with future Grafana major versions?