Include remote-site status data in a Checkmk recovery plan

Bottom line: Distinguish the central site configuration backup from remote-site status recovery, and require matching Checkmk version/edition plus separately protected encryption keys.

Source fact: what the authority says

The Checkmk backup guide limits a GUI backup to the local site; a central-configuration site also includes the configuration of its centrally managed remote sites. Complete coverage of remote-site status data requires configuring backups on those remote sites as well. The documented restore prerequisites require the exact same Checkmk version and edition on source and target; the operating-system platform may differ. Encrypted-backup recovery needs the saved encryption key, and downloading or uploading that key also requires its passphrase.

What the source does not establish

This article inventories site recovery prerequisites and coverage, not a claim that a restore has succeeded. It does not prescribe historical-data exclusions, prove application recovery or approve broader remote-site configuration access.

Applicability questions

• Which central and remote sites require configuration, history or status recovery?
• What exact Checkmk version and edition will the recovery target use?
• Who can retrieve the saved encryption key and passphrase securely?
• Where is the independent backup and restore observation for each required site?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a recovery matrix with one row per site and separate columns for configuration and required operational data. Name the backup job and controlled artifact reference for each row. Have the distributed-monitoring owner identify remote status coverage rather than treating the central configuration archive as the entire environment’s recovery set.

Prepare the target software requirements before selecting an archive for rehearsal. Record the exact source and target version and edition, and resolve a mismatch through the current supported procedure. Keep the operating-system choice separate from that exact Checkmk match; do not infer software compatibility from a successfully copied archive.

Review backup-key custody with the authorized recovery operator. Record protected references and retrieval responsibilities without placing the key or passphrase in the general recovery matrix. Include a second authorized operator in a tabletop retrieval review so the plan does not depend on the backup creator’s memory.

Where remote-site backup configuration is needed, arrange the approved access and restore its normal restrictions after the maintenance task. Keep archive destinations and retained data choices explicit. Schedule a bounded isolated restore for the required site population, with production overwrite and unrelated configuration changes outside the trial.

Verification and evidence

Proposed verification: select a controlled test archive and a target with the documented matching software. Have the recovery operator follow the approved key-retrieval and restore procedure, retaining actual completion or failure observations. Compare the recovered configuration with the site’s written inventory rather than stopping at file-transfer success.

Inspect the separately required remote-site status or history data through the agreed test scope. Record missing coverage as a recovery finding and check normal remote configuration restrictions afterward. Preserve archive identities, software match, redacted key references and observed results without claiming that an unperformed full-environment recovery has passed.

Official references

• Checkmk — Backups — official product documentation; confirm the installed release and configuration.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.