Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

What's the best practice for CM Disaster recovery


We have a client that has multiple sites and have just implemented a DR site 600 miles from the main cluster.

I would like to know what others have done in a DR situation. there isnt enough BW between the HQ and DR for split cluster.

The main thing is keeping the DR site up to date with user ext and VM information.

At this stage im thinking the best bet is to have dedicated

1 x CallManager

200 phones

1 x VG 2811 +FXS 4 port card

1 x unity connection for VM

An up date the data manualy

Any better ideas



Re: What's the best practice for CM Disaster recovery

Make sure the RTT between pub and sub is < 40ms. The one DR project I did had a gigaman between the two sites and rtt was < 2ms.


Re: What's the best practice for CM Disaster recovery

Untested, but here are some ideas:

Use BARS on the CallManager and DiRT on the Unity server to back up directly to shares on the CallManager and Unity servers at the DR site, every night. The CallManager and Unity servers at the DR site should be installed with the same versions of software at the main site, but left totally unconfigured other than that.

When you need to invoke your DR plan, it's as simple as running the restore process on those servers, using the backup files that are already stored on each server from your automatic scheduled backups. This only takes a few minutes per server. This takes care of Unity completely, but the CallManager would need more work.

The CallManager will get configured with the MAC addresses of the old phones which are presumably still at the host site, but unless you already know where everyone's going to sit at the DR site, you are probably going to have to have a process anyway where you manually change the MAC address on phone profiles to match phones you have at the DR site. Alternately, you could install Extended Services and TAPS, and relax the TAPS security option while you're getting your DR site set up so you can register the new phones on top of your "already configured" phone profiles in CallManager. Another alternative is to go ahead and fully configure new phone profiles for the DR-site phone MAC addresses in your production CallManager, such that they share all their lines with the user's "real" phone. The DR-site phone profile will normally sit there unregistered, but when you restore at the DR site, the DR phone will register and the "real" phone will sit unregistered.

If you don't have the same gateway hardware, you'll have to configure CallManager for that new gateway after the restore. Again you could pre-configure that gateway in your production CallManager, and with creative use of route lists and so forth, you could get calls to automatically use that gateway after restore and deal with any local calling-area changes.

Any DR site recovery procedure is going to be complicated. I don't know if you're just trying to operate the DR site, or if you intend to operate your other remote sites off this DR site CallManager. There are more things you have to do, this is just an overview of one possible method. You might experiment with it and see if it meets your needs. It would benefit you to order your DR site servers with RAID and with an extra RAID drive to sit on the side, so you always have a "clean" just-installed image you can revert to after restores and experimentation.

New Member

Re: What's the best practice for CM Disaster recovery

Thanks for taking the time to write a thesis appreciate it 5 points !

Im thinking as a first choice We will wont bother with BARS and DIRT and restores.

There will be ofsite back ups sure.

But they wont be 600 miles away at the DR site. They would be in an ofsite location 30 40 miles from HQ.

I dont see fit to copy the CM tar over the wan every night as there is more important things such as peoplesoft syncs etc.

I'd like to see imediate DR action.

Users might not be there imediatly as they would need to get flights to DR site etc.

But certainly calls could be intercepted by the receptionist in the DR site or go to VM which they could check by dialing the Pilot. Also communicator phones could be used registered to the DR CM.

What Im suggesting to the client

1 x CallManager 7835H Raid 1

1 x Unity connection (no Unity UM for DR Unity Connection is much more cost effective) having said that I Will Price unity 4.1 UM for them.

1 x VG configured with doormant ready to go PRI Telco can swing existing DID's from HQ to it in a DR situation.1 x PVDM2-64 upgrade use for HW conf

1 x FXS 4 port for FAX

1 x 3750 PoE stack 240 ports

A dedicated PC for AC.

So I propose this method.

When a new user starts they are configured on two systems.

That way the work is done and its upto date its an extra minute of work for reliable up to data information.

IF a user "EXEC" doesnt like his seat at DR he can up and move take the phone somewhere else all ports are PoE.

The client can take care of Exchange redundancy all existing saved Voicemails will be available from outlook and can be played by widows Media player.

User then have access to existing VM messges left on the out of action exchange server.

NO sites will run of DR HW.


for the input.