CUCM发行商从用户数据库的节点恢复没有前期备份或根访问权限

简介

本文描述如何恢复从用户数据库(DB)的Cisco Unified Communications Manager (CUCM)发行商节点，不用前期备份或根访问权限。

背景

在CUCM中更早版本，发行商节点被认为结构化查询语言(SQL) DB的唯一的授权来源。结果，如果发行商节点丢失的归结于硬件故障或文件系统损坏，恢复它的唯一方法是重新安装和恢复从灾难恢复系统(DR)备份的DB。

一些客户没有保留是过时的适当的备份，也没有备份，因此唯一选择是重建和重新配置发布服务器节点。 

在CUCM版本8.6(1)，新特性介绍为了恢复从用户数据库的发行商DB。本文描述如何利用此功能为了顺利地恢复从用户的发行商DB。

思科强烈建议您保留整个集群的一个全双工灾难恢复框架(DRF)备份。因为此进程只恢复CUCM DB配置，其他数据，例如证书， Music on Hold (MoH)和TFTP文件，没有被恢复。为了避免这些问题，请保留一个全双工集群DRF备份。 

注意：思科建议您查看并且熟悉在本文描述的整个过程，在您开始前。  

聚集团星数据

在您重新安装发行商前，非常重要的是您采集关于上一个发行商的有关详细信息。这些详细信息必须匹配原始发行商安装：

• IP 地址
• 主机名
• 域名
• 安全密码短语
• 确切的CUCM版本
• 已安装思科选项包(COPS)文件

为了获取在列表的前三个项目，请进入show network cluster命令在当前用户节点CLI ：

admin:show network cluster
172.18.172.213 cucm911ccnasub1  Subscriber authenticated
172.18.172.212 cucm911ccnapub  Publisher not authenticated - INITIATOR
 since Tue Dec 3 12:43:24 2013
172.18.172.214 cucm911ccnasub2  Subscriber authenticated using TCP since
 Sun Dec 1 17:14:58 2013

在这种情况下， IP地址是172.18.172.212，主机名是cucm911ccnapub，并且没有为发行商配置的域名。   

安全密码短语(在列表的第四个项目)从站点文档获取。如果对安全密码短语是不确定的，请做一个最佳效果猜测，并且您能尝试验证和更正它当必要时根据CUCM版本。如果安全密码短语不正确，则集群中断要求为了校正情况。 

为了检索确切的CUCM版本和已安装COPS文件(在列表的最后两个项目)，请采集从active命令的show version的系统产出量：

admin:show version active
Active Master Version: 9.1.2.10000-28
Active Version Installed Software Options:
No Installed Software Options Found.

在这种情况下，版本9.1.2.10000-28安装没有添加COPS文件。 

注意：很可能，一些COPS文件在发行商以前安装，但是未安装在用户，反之亦然。请使用此输出作为仅指南。

终止在所有用户的复制

当发行商安装时，非常重要的是复制不设置并且删除当前用户Dbs。为了防止此，请输入使用情况dbreplication stop命令在所有用户：

admin:utils dbreplication stop
********************************************************************************
This command will delete the marker file(s) so that automatic replication setup
is stopped
It will also stop any replication setup currently executing
********************************************************************************

Deleted the marker file, auto replication setup is stopped

Service Manager is running
Commanded Out of Service
A Cisco DB Replicator[NOTRUNNING]
Service Manager is running
A Cisco DB Replicator[STARTED]

Completed replication process cleanup

Please run the command 'utils dbreplication runtimestate' and make sure all nodes
are RPC reachable before a replication reset is executed

安装CUCM发行商

采集适当的版本的可启动的镜像，并且执行安装与升级对适当的版本。

注意：多数CUCM Engineering Special (ES)版本已经是可启动的。

安装发行商并且指定以前被提及的IP地址、主机名、域名和安全密码短语的正确值。 

更新在发行商的Processnode值

注意：发行商一定知道至少一用户服务器为了恢复从该用户的DB。思科建议您添加所有用户。 

为了获取节点列表，请输入运行SQL挑选名称，说明，从processnode at命令的nodeid一个当前用户的CLI。命名值可以是主机名、IP地址或者完全合格的域名(FQDN)。

如果运行CUCM版本10.5(2)或以上， disaster_recovery准备恢复pub_from_sub命令的使用情况在发行商CLI必须运行，在您能继续添加节点到System > Server前：

在您接收节点列表后，请导航对System > Server并且添加所有命名值除EnterpriseWideData之外到发布服务器统一的CM管理页面。命名值必须对应于主机名/IP地址字段在System > Server菜单。

admin:run sql select name,description,nodeid from processnode
name               description     nodeid
================== =============== ======
EnterpriseWideData                 1
172.18.172.212     CUCM901CCNAPub  2
172.18.172.213     CUCM901CCNASub1 3
172.18.172.214     CUCM901CCNASub2 4

注意：默认安装添加发行商主机名到processnode表。如果名称列列出发行商的，一个IP地址您也许必须更改它到IP地址。在这种情况下，请勿删除发行商条目，然而打开并且修改当前主机名/IP地址字段。 

重新启动发行商节点

为了重新启动发行商，在processnode更改完成后，请输入使用情况系统重新启动命令：

admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes

Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.

Shutting down Service Manager. Please wait...
 \Service Manager shutting down services... Please Wait

Broadcast message from root (Tue Dec  3 14:29:09 2013):

The system is going down for reboot NOW!
Waiting .

Operation succeeded

验证团星验证

在发行商重新启动，如果正确地后做了变动，并且安全密码短语正确，集群应该在已验证状态。为了验证此，请进入cluster命令的show network ：

admin:show network cluster
172.18.172.212 cucm911ccnapub  Publisher authenticated
172.18.172.213 cucm911ccnasub1  Subscriber authenticated using TCP since
 Tue Dec 3 14:24:20 2013172.18.172.214 cucm911ccnasub2  Subscriber authenticated using TCP since
 Tue Dec 3 14:25:09 2013

注意：如果用户没出现如验证，参考本文的Troubleshoot部分为了解决此问题，在您继续前。

执行新的备份

如果上一个备份不是可用的，请执行在DR页的一个集群备份。

注意：虽然您能使用用户DB恢复，备份仍然要求为了恢复非DB组件。

如果备份不是可用的，则请执行新的;如果备份已经存在，则您能跳过此部分。 

添加备份设备

请使用导航菜单为了导航到灾难恢复系统，并且添加备份设备。

开始手动备份

在备份设备被添加后，请开始一个手动备份。

注意：非常重要的是发行商节点有注册的CCMDB组件。

从用户DB的发行商恢复

在灾难恢复系统页，请导航恢复>恢复向导。如果一个当前备份是可用的，并且跳过了前面部分，请检查所有在挑选特征部分的功能复选框：企业许可证管理器(榆木)若有， CDR_CAR和统一通信管理器(UCM)。如果使用在前面部分被执行的一个备份，请检查仅UCM复选框：

单击 Next。检查发行商Node复选框(CUCM911CCNAPUB)，并且选择恢复发生的用户DB。然后，请点击恢复。

恢复状态

当恢复到达CCMDB组件时，状态文本应该出版作为恢复从用户备份端口:的发行商

进行在发行商DB的健全性检查

在您重新启动并且设置复制前，它是良好的做法验证恢复是成功的，并且发行商DB包含必填信息。保证这些查询返回在发布服务器和用户节点的同样值，在您继续前：

• 从设备运行SQL挑选计数(*)
• 从最终用户运行SQL挑选计数(*)

重新启动团星

在恢复完成后，请输入使用情况系统重新启动on命令每个节点。从每个用户跟随的发行商开始。

admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes

 Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.

Shutting down Service Manager. Please wait...
 \ Service Manager shutting down services... Please Wait

Broadcast message from root (Tue Dec  3 14:29:09 2013):

The system is going down for reboot NOW!
Waiting .

Operation succeeded

验证复制设置需求

导航对报告页的Cisco Unified并且生成一份Unified CM数据库状态状态报告。很可能复制也许没有设置，但是请注意Unified CM主机，统一CM Rhosts，并且统一的CM Sqlhosts文件匹配发行商。如果他们不，不配比的那些节点将需要再重新启动。如果这些文件不配比，请勿继续对下一步也请勿重置复制。

复制设置

从属在版本，复制也许不自动地设置。为了检查此，等待所有服务开始和输入使用情况dbreplication runtimestate命令。状态值为0表明设置进展中，而值为2表明复制为该节点成功设置。

此输出表明复制设置进展中(状态出现作为0两的节点) ：

此输出表明复制成功设置：

如果任何节点显现状态值为4，或者，如果复制不在几个小时之后成功设置，请输入使用情况dbreplication reset all命令从发行商节点。如果复制继续发生故障，参考在Linux设备型号Cisco条款的故障排除CUCM数据库复制关于如何排除故障问题的更多信息。 

波斯特恢复

因为DB恢复不恢复所有上一个组件，必须手工安装或恢复许多服务器级别项目。

启动服务

DRF恢复不启动任何服务。导航对Tools > Service激活，并且根据从Unified维护性页的站点文档启动发行商应该管理的所有必要的服务， ：

安装未恢复的数据

如果完全备份不是可用的，您必须再生产某些手动配置。特别，介入证书并且TFTP功能的那些配置：

• MoH文件
• 设备装箱
• 拨号计划(非北部美国编号方案(NANP)正在拨号)
• 区域设置
• 任何其他其他COPS文件
• 手工以前上传给发行商的任何文件(如果它是TFTP server)
• 简单网络管理协议(SNMP)社区字符串
• Extension Mobility交叉团星(EMCC)，簇之间位置带宽管理器(LBM)和簇之间查找服务的(ILS)大批证书出口
• 证书交换为巩固中继、网关和会议桥

注意：对于mixed-mode集群，您必须再运行证书信任列表(CTL)客户端。

故障排除

此部分描述也许造成此步骤发生故障的多种方案。

团星不验证

如果集群不验证，两个多数常见原因是不匹配的安全passphrases和连通性问题在TCP端口8500。

为了验证集群安全passphrases配比，请输入使用情况Create报告平台at命令两节点CLI，并且检查Hash值从platformConfig.xml文件。这些在发布服务器和用户节点应该配比。

  <IPSecSecurityPwCrypt>
    <ParamNameText>Security PW for this node</ParamNameText>
    <ParamDefaultValue>password</ParamDefaultValue><ParamValue>0F989713763893AC831812812AB2825C8318
    12812AB2825C831812812AB2825C </ParamValue>
  </IPSecSecurityPwCrypt>

如果这些配比，请验证在端口8500的TCP连接。如果他们不配比，也许有困难，当您尝试修复密码短语由于包围步骤在CUCM代码时的几个缺陷：

• Cisco Bug ID CSCtn79868 -重置仅sftpuser密码的pwrecovery工具
• Cisco Bug ID CSCug92142 - pwrecovery工具不更新内部用户密码
• Cisco Bug ID CSCug97360 -在pwrecovery工具的selinux否认
• Cisco Bug ID CSCts10778 -为安全密码恢复流程投掷的否认
• Cisco Bug ID CSCua09290 - CLI “set password用户安全”没有设置正确apps密码
• Cisco Bug ID CSCtx45528 - pwd重置好cli的回归，但是不更改密码
• Cisco Bug ID CSCup30002 - DB服务发生故障，在更改在CUCM 10.5的安全密码以后
• Cisco Bug ID CSCus13276 - CUCM 10.5.2安全密码恢复开始的原因DB在重新启动

如果CUCM版本包含所有的修正这些问题，最容易的解决方案将完成在Cisco Unified通信操作系统的管理指南选派的密码恢复流程，发布10.0(1)在所有节点。如果CUCM版本不包含这些问题的修正，则Cisco技术支持中心(TAC)也许有能力执行应急方案，从属在情况。 

恢复不处理CCMDB组件

如果恢复不列出DB组件，则很可能，备份不包含DB组件。保证发行商DB运行，并且能接受查询，并且执行一个新的备份。

复制失败

参考在Linux设备型号Cisco条款的故障排除CUCM数据库复制为了排除故障复制失败。

电话不注册也不无法访问服务

因为DB恢复不恢复任何证书，如果发行商是主要的TFTP server，签署人不同的。如果电话信任用户托拉斯验证服务(TV)证书和TCP端口2445是开放的在电话和TV服务器之间，应该自动地解决问题。为此，思科建议您维护全双工集群DRF备份。 

在版本8.6之前的CUCM版本也许也有证书问题，与一个上一个成功的备份，由于Cisco Bug ID CSCtn50405。

注意：参考通信管理器安全默认情况下和ITL操作和故障排除Cisco条款关于如何排除故障最初的托拉斯列表(ITL)文件的更多信息。