The callmanager is based on a single subscriber database model with real-time replication to the Subscribers. The Publisher is the owner of the database and can read/write in all fields. The subscribers are having a copy of the database so they can function without the publisher (so the publisher is not a single point of failure) but can only write into the fields for the user facing functions (e.g. MWI, DND, Call forward etc). In the case of a publisher failure please don't get the idea to reboot a subscriber, it will not get the updated copy of the publisher database if that one is down.
It is not possible to replicate a Publisher database from a subscriber by any built-in function so you better have a decent backup of the publisher. There is a chance to do what you wanted to do with a third party tool called Uplinx. This allows you to do a report on the subscriber database during runtime and reconstruct most of the database in a publisher after a new install. This method is not supported by cisco in any means and also may leave some settings untouched. You need to do thorough testing to make sure if everything is back to the original state.
Another twist to the situation.
I installed a fresh publisher, it synced with the existing subscriber hence all my devices including gatways and phones vanished from cluster, but the phones and gateways are still fully functional.Since i cant see them from the cluster (new pub and existing sub) i cant control them.
However when i shut down the fresh pub, all devices (including phones and gateways) showed up on the sub.At list i have a view of them and ofcourse cant edit or do anything.
Why cant cisco build a sub that can be used to recover a pub!
If you look at the possibilities you have in IDS (IBM sql database) you see that there are structures to have redundant publishers and also the possibility to promote a subscriber to a publisher after the publishers death. Both of these structures are not possible in the UCM database and have never been possible since Selsius invented the original Callmanager. The reason is simple: Promoting a Subscriber would mean your publisher will be geographically in a different place after this move and possibly resides at a suboptimal place. A redundant publisher means a way more complex replicaton schedule in a real-time replication based sql database. Because of this Cisco had good reasons not to extend the structure (which also would mean a more complex DB-structure with these features). The publisher is not a single point of failure because the subscriber can continue without the publisher. You just need a current backup or you extract the database with 3rd party tools as long you did not reboot the subscriber after the publisher quit it's duty