Grafana backup and restore

Restore the database backup and the configuration, provisioning files and plugin folders into a separate scratch environment, start Grafana there, and check each function a user or alert depends on. A restore is only proven when the instance starts cleanly against the restored database and the checks below pass. Keep the scratch instance off production networks and disable outbound notifications so a test does not send real alerts or write to live data sources.

• Confirm that users can sign in through the same identity provider or local accounts.
• Confirm each data source connects and returns data for a known time range.
• Open representative dashboards and confirm panels render with expected values.
• Confirm provisioned data sources, dashboards and alert rules load at startup.
• Confirm alert rules evaluate and their states change as expected.

Start with the startup logs and the database, because every later check depends on Grafana opening its database cleanly. Look for migration errors, missing plugin warnings and provisioning failures in the log output. Then check that the restored database version matches the Grafana version that created the backup, since an unexpected schema mismatch will stop the instance before any user-facing test can run.

Provisioned data sources, dashboards, plugins and alerting resources are defined in YAML or JSON files loaded at startup, so the restore test should compare the running instance with the files in Git. Confirm that every provisioned data source appears and that dashboards from provisioning files are present with their expected folders. Grafana documents further as-code options, including Terraform and Git Sync, which you can use to reconcile differences found during the test.

Test on a fixed schedule and after any substantive change, such as a Grafana minor or major upgrade, a database move or a change to authentication. For organizations in scope of DORA, Article 11(6) requires ICT response and recovery plans to be tested at least yearly and after substantive changes, including switchovers to backups and redundant capacity, for entities other than microenterprises. Your own risk policy and internal audit may require more frequent tests, so confirm the schedule with your compliance owner.

DORA expects tests to be run and their outcomes recorded as part of the recovery plan, so each test should leave evidence. Record the date, the backup set used, the Grafana and database versions, the checks performed, the results and any follow-up actions. DeployOpen prepares systems, controls and evidence for compliance assessments, but auditors and certification bodies issue the assessment outcome, so ask your assessor which evidence format they expect.

The test should be run by someone who did not perform the backup, using the documented restore procedure, so gaps in the runbook surface. Operations engineers usually run the technical checks, while service owners confirm dashboards and alerts reflect current responsibilities. Ask whether your internal team has time to run the test in a separate environment, and whether a partner will run it under a written scope with agreed deliverables.

The main costs are staff time, a scratch environment with compute and storage, and access to test copies of data sources. Cost rises with the number of data sources, the number of dashboards and alert rules, the number of identity integrations to verify, and how much of the restore is manual. Costs are typically one-time for the first test design and recurring for each scheduled run. Ask any partner for a quote that separates test design, execution, evidence and remediation.

The cost depends on the scope agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that scope. The main cost drivers are the number of Grafana instances, the database engine and where it runs (SQLite, MySQL or PostgreSQL), how many plugins and provisioning files need capturing, where backups are stored and how restores are tested. One-time work covers the backup design, scripts or jobs, the restore runbook and the first full restore test. Recurring work covers monitoring backup jobs, periodic restore tests and changes after Grafana upgrades. Ask any quote to separate these two groups and to state which database engine and storage target it assumes.

Duration follows scope rather than a fixed figure, so the honest answer is that it grows with the number of instances, the database engine and the number of restore paths you need to prove. A single instance with a managed PostgreSQL or MySQL database and provisioning already in Git is a much smaller piece of work than several instances with plugin folders, custom storage and a documented recovery process. Your team should confirm the target recovery scenarios first, since those decide the test effort. The written scope sets the timeline for your engagement.

Expect to provide access to the Grafana servers and the database host, a list of instances and their deployment method (package, container or Helm chart), and the location of any provisioning files and dashboards already stored in Git. You will also need to name the storage target for backups, the retention you need, and who approves restore tests. Access to a non-production environment for restore testing is important, because a backup is only proven when a separate instance comes up and shows the expected dashboards, data sources and users. Confirm these items with your security team before scope is agreed.

Yes, many teams can, provided they have someone comfortable with the database engine, Linux administration and secret handling. The skills that matter most are dumping and restoring the Grafana database, capturing configuration and plugin folders, keeping provisioning files in version control and running a clean restore on a second host. The harder parts are often the unwritten ones: defining recovery priorities, protecting backup data and proving the restore works under time pressure. Ask whether your team has capacity to run restore tests on a schedule, because that recurring work is where internal efforts usually slip.

Test often enough to match your recovery requirements and any framework you are assessed against. The CIS Controls v8.1 Safeguard 11.1 asks for a documented recovery process reviewed annually, and DORA Article 11(6) requires ICT response and recovery plans to be tested at least yearly and after substantive changes, which applies to financial entities. Beyond those reference points, retest after every Grafana major upgrade, a change to the database engine, a new plugin or a change in the storage target. A restore test should bring up a separate instance, check dashboards, data sources, users and alert configuration, and record the result.

Not entirely. Grafana Cloud reduces the infrastructure you run, but your organization still needs to decide what its dashboards, alert rules and provisioning files are worth, where they are recorded, and how they can be rebuilt if the service or an account is lost. Teams that keep dashboards as code in Git can rebuild in another environment, whereas teams that rely only on the UI carry more risk. The Grafana pricing page lists tiers with different platform fees and usage charges, so a cloud decision should be made with the total cost and the exit path in view. Confirm what export and recovery options your chosen tier supports.

The most common failures come from missing pieces rather than corrupted data. Typical problems include a database dump restored into the wrong engine version, a grafana.ini that points at a different database host or a missing encryption secret, plugins that are absent or at a different version, and provisioning files that no longer match the restored database. Restore order also matters: the database and configuration should exist before Grafana starts, and provisioned resources should load in a predictable sequence. Keep a checklist for each item and confirm it during every restore test.