# Recover the Ceph Monitor Store Using OSDs

DevFeed: [Recover the Ceph Monitor Store Using OSDs](<https://devfeed.tech/articles/recover-the-ceph-monitor-store-using-osds-12335.md>)

Original publisher: [Read original article](<https://ceph.io/en/news/blog/2026/mon-recovery-from-osds/>)

Author: Eugen Block, crossposted by Anthony D'Atri

Published: 2026-07-04T00:00:00Z

Content type: article

Language: en

Sources: [Ceph Blog](<https://devfeed.tech/sources/ceph-blog.md>)

Topics: [ceph](<https://devfeed.tech/topics/ceph.md>), [monitor](<https://devfeed.tech/topics/monitor.md>), [Script](<https://devfeed.tech/topics/script.md>), [Containers](<https://devfeed.tech/topics/containers.md>), [log management](<https://devfeed.tech/topics/log-management.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [ceph](<https://devfeed.tech/tags/ceph.md>), [containers](<https://devfeed.tech/tags/containers.md>), [en-article](<https://devfeed.tech/tags/en-article.md>), [en-blog-post](<https://devfeed.tech/tags/en-blog-post.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [logging](<https://devfeed.tech/tags/logging.md>), [logs](<https://devfeed.tech/tags/logs.md>), [mon](<https://devfeed.tech/tags/mon.md>), [monitor](<https://devfeed.tech/tags/monitor.md>), [recovery](<https://devfeed.tech/tags/recovery.md>)

## AI overview

This blog post presents a general procedure for recovering a failed Ceph Monitor store by collecting osdmaps from existing OSDs, with additional considerations for cephadm-managed container deployments. It automates osdmap collection and basic logging while leaving the store rebuild and client authentication steps for careful manual inspection. The procedure applies only to non-encrypted OSDs, and the article emphasizes the importance of backing up dmcrypt/LUKS keys and reviewing host logs.

## Source excerpt

Introduction ¶ A few weeks ago I helped a Ceph user to recover his broken cluster (see this thread). Basically, after his Monitors stopped working he re-deployed a new cluster with the same Ceph FSID and attached the existing OSDs to the re-deployed hosts. But it's not that easy to re-activate those OSDs because the new Monitors don't have the old osdmap, hence they don't know anything about the existing OSDs. So how did we fix that? This scenario can be considered a total Monitor store failure. There's a documented procedure in the upstream docs, unfortunately it's written for non-cephadm clusters and doesn't contain many details about subsequent steps. When Ceph daemons run within containers there are more things to consider. So I decided to write this blog post and add some more details to the procedure, targeting mainly clusters managed by cephadm. But the recovery procedure doesn't specifically require cephadm-specific commands, so it can be considered as a general guideline how to recover from a Monitor store loss, just with some extra details about cephadm deployments. This procedure only works for non-encrypted OSDs. If you are using dmcrypt (LUKS) OSDs, make sure you have a backup of the keys, otherwise your data is lost forever! But there is some development, a user in Slack pointed me to this PR which adds a backup mechanism for Monitors, probably available in the upcoming Umbrella release. Note that the PR also contains this statement: Monitor backups complement, but do not replace, the existing Monitor recovery procedures The procedure covered by said docs is already written in script form, so I used that as a template and extended it for cephadm usage and included some very basic logging. It collects the osdmaps from all OSDs and contains the necessary considerations regarding containers. I decided to automate only the osdmap collection, not all required steps of the store rebuild procedure (e. g. Monitor store rebuild, client auth, etc.) because the r