Cisco Support Community
Community Member

Disaster Recovery for CUCM

I'd be interested to hear about other people's strategies and plans for continuity of service with CUCM, if people are open to sharing the info.

We built our environment with as much resilience as we could reasonably plan. We have the publisher and two subscribers in Office A, with two more subscribers in Office B (our largest offices). This cluster handles phones for ten offices, all linked on an MPLS network with redundant links in each site. Gateways in each site are configured with SRST. Hardware is all set up (where possible) with dual power supplies, dual NICs to dual switches, all that good stuff. DNS, DHCP, etc all redundant and distributed. And so on and so forth.

However - there's still that old "Achilles heel" in CUCM - the dependence on a single publisher for extension mobility, moves adds and changes, etc.

Like many businesses, we have continuity plans that we've developed, refined and rehearsed over the years. We plan for the possibility of losing Office A and everything in it suddenly (think massive earthquake or crashing plane scenarios).

The best I've been able to come up with for CUCM is to have DRS configured to backup the cluster every night to a server in Office A, with that disk volume replicated near-real-time to Office B. The plan is that in the event of disaster we would rebuild one of the two subscribers in Office B as a new publisher, restore the DRS backup to it, and we're back up and running, losing at worst case 24 hours of MAC activity. We've tested this process in an isolated lab environment and we're confident it works.

Right now we're running on MCS servers. Would we gain features by moving to UCS? We're now so used to real-time replication and fail-over of other services (file servers, email systems, etc) using technology from VMware, NetApp, etc, that the continuity process for CUCM seems quite inadequate. Would CUCM on UCS allow us a cleaner, ideally automated, transition?

Has anybody come up with any interesting alternative ideas?

CreatePlease to create content