03-09-2016 10:04 AM - edited 03-19-2019 10:50 AM
We are in the process of testing disaster recovery for our CUCM infrastructure.
We did a backup of our current cucm publisher and wanted to restore it on another cucm server we built. The problem we are having is that when we try to initiate a restore of the backup on the new server, the new cucm server does not see the backup files.
Both servers have the same name and ip address but the new server is on an isolated network.
How can we restore the backup from the live publisher to the new standby cucm publisher.
Solved! Go to Solution.
04-15-2020 07:55 PM - edited 04-20-2020 10:28 AM
Edited response on later findings:
On top of verifying server IP, hostname, domain, and DNS servers, you'll get the same error ("Unable to restore the data - Cannot find the deployment type, Restore completed...") if you're restoring your backup from a cluster that had subscribers (CUCM or IMP) there's sometimes an issue with restoring all backup components at one time. Running through them individually allowed for restore and identified the problem component, but this is super time consuming since you have to restart the affected server(s) between restores.
04-20-2020 07:45 AM
@LeeAnnChilders wrote:On top of verifying server IP, hostname, domain, and DNS servers, you'll get the same error ("Unable to restore the data - Cannot find the deployment type, Restore completed...") if you're restoring your backup from a cluster that had subscribers (CUCM or IMP) and you haven't already added them in CM Administration > Systems > Servers. I'm not sure if formatting matters here (FQDN vs. IP) but I stick to adding them exactly the same as before. Since you were/are running this in a test environment, you may or may not have DNS availability. If not, IP it is...
We've carried out Publisher restores a number of times without adding the subs to the database first. The process we've followed was clean install of Publisher (correct version and details etc), connect it to the network with the existing Subscribers still live, then carry out the DRS restore.
That was the process in the Cisco document, and to my mind if you created the subs on the empty publisher before the restore, don't you run the risk of the empty database being pushed out to the subscribers?
Having said that I still have a quick check of the documentation for the exact version each time I carry this out.
04-20-2020 10:25 AM
This was actually bad info (my mistake). The issue ended up lying in the backup. Restoring components had to be done one at a time and that is what officially caused the error.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide