目录

简介

背景

收集集群数据

停止所有订阅服务器上的复制

安装CUCM发布服务器

更新发布服务器上的进程节点值

重新启动发布服务器节点

验证集群身份验证

执行新备份

添加备份设备

启动手动备份

从订阅服务器数据库恢复发布服务器

恢复状态

对发布服务器数据库运行健全性检查

重新启动集群

检验复制设置要求

复制设置

恢复后

激活服务

安装未还原的数据

故障排除

集群不进行身份验证

恢复不处理CCMDB组件

复制失败

电话未注册或无法访问服务

简介

本文档介绍如何从用户数据库恢复Cisco Unified Communications Manager(CUCM)发布方节点，而无需事先备份或根访问。

背景

在CUCM的早期版本中，发布者节点被认为是结构化查询语言(SQL)数据库的唯一权威源。

因此，如果发布方节点由于硬件故障或文件系统损坏而丢失，恢复它的唯一方法是重新安装数据库并从灾难恢复系统(DRS)备份中恢复数据库。

某些客户没有保留正确的备份，或者备份已过期，因此唯一的选择是重建并重新配置发布服务器节点。

在CUCM版本8.6(1)中，引入了一项新功能，以便从用户数据库恢复发布者数据库。

本文档介绍如何利用此功能从订阅服务器成功还原发布服务器数据库。

Cisco强烈建议您保留整个群集的完整灾难恢复框架(DRF)备份。

由于此过程仅恢复CUCM数据库配置，因此不会恢复其他数据，如证书、通话等待音乐(MoH)和TFTP文件。为了避免这些问题，请保持完整群集DRF备份。

注意：思科建议您先检查并熟悉本文档中介绍的整个流程，然后再开始操作。

收集集群数据

在重新安装发布器之前，请务必收集有关上一个发布器的相关详细信息。这些详细信息必须与原始发布服务器安装相匹配：

- IP 地址

- 主机名

- 域名

- 安全口令

- 精确CUCM版本

- 已安装的思科选项包(COP)文件

要检索列表中的前三个项目，请在当前用户节点CLI中输入show network cluster命令：

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版本和安装的COP文件（列表中的最后两个项目），请从show version active命令收集系统输出：

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安装时没有附加COP文件。

注：可能一些COP文件之前安装在发布服务器上，但并未安装在用户上，反之亦然。此输出仅用作指南。

停止所有订阅服务器上的复制

安装发布服务器时，复制操作不能设置和删除当前订阅服务器DB至关重要。要防止这种情况，请对所有用户输入utils dbreplication stop命令：

admin:utils dbreplication stop

********************************************************************************

This command can delete the marker file(s) so that automatic replication setup

is stopped

It can 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工程特殊(ES)版本已经可以启动。

安装发布器并为前面提到的IP地址、主机名、域名和安全口令指定正确的值。

更新发布服务器上的进程节点值

注意：发布方必须知道至少一个订用服务器，才能从该订用方恢复数据库。思科建议您添加所有订户。

要检索节点列表，请在当前用户的CLI中输入run sql select name，description，nodeid from processnode命令。

名称值可以是主机名、IP地址或完全限定域名(FQDN)。

如果运行CUCM版本10.5(2)或更高版本，则必须先在发布方CLI上运行utils disaster_recovery prepare restore pub_from_sub命令，然后才能继续向System > Server添加节点：

警告：许多使用CUCM 10.5(2)版或更高版本的人员跳过命令utils disaster_recovery prepare restore pub_from_sub；但是，这是一个关键命令。请勿跳过本文档中的任何步骤。

收到节点列表后，导航到System > Server，并将除EnterpriseWideData之外的所有名称值添加到Publisher Server Unified CM Administration页面。

名称值必须与System > Server菜单上的Host Name/IP Address字段对应。

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表。如果name列列出发布服务器的IP地址，您可以将其更改为IP地址。在这种情况下，不要删除发布者条目，而是打开并修改当前的主机名/IP地址字段。

重新启动发布服务器节点

要在processnode更改完成后重新启动发布服务器，请输入utils system restart命令：

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

验证集群身份验证

发布服务器重新启动后，如果更改正确且安全口令正确，则集群必须处于已验证状态。要验证这一点，请输入show network cluster命令：

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 2013

172.18.172.214 cucm911ccnasub2  Subscriber authenticated using TCP since

Tue Dec 3 14:25:09 2013

注意：如果用户未显示为已验证身份，请参阅本文档的故障排除部分，以便在继续操作之前解决此问题。

执行新备份

如果没有可用的以前备份，请在DRS页面上执行群集备份。

注：虽然可以使用订用服务器数据库进行恢复，但恢复非数据库组件仍需要备份。

如果没有可用的备份，则执行一个新备份；如果备份已存在，则可以跳过此部分。

添加备份设备

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

启动手动备份

添加备份设备后，启动手动备份。

注意：发布方节点注册了CCMDB组件非常重要。

从订阅服务器数据库恢复发布服务器

在Disaster Recovery System页面中，导航到Restore > Restore Wizard。

如果当前备份可用，并且已跳过上一部分，请选中“选择功能”部分中的所有功能复选框：企业许可证管理器(ELM)（如果可用）、CDR_CAR和Unified Communications Manager(UCM)。

如果使用在上一节中执行的备份，请仅选中UCM复选框：

单击 Next。选中publisher node复选框(CUCM911CCNAPUB)，并选择从中进行恢复的用户数据库。然后，单击Restore。

恢复状态

当恢复到达CCMDB组件时，状态文本必须显示为从订用服务器备份恢复发布服务器:

对发布服务器数据库运行健全性检查

在重新启动并设置复制之前，比较好的做法是验证恢复是否成功，以及发布方数据库是否包含所需信息。

请确保这些查询在发布服务器和订阅服务器节点上返回相同的值，然后再继续：

- 从设备运行sql select count(*)

- 从最终用户运行sql select count(*)

重新启动集群

恢复完成后，在每个节点上输入utils system restart命令。从发布者开始，然后是每个订用者。

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 Reporting页面并生成Unified CM数据库状态报告。

很可能尚未设置复制，但重要的是要确保Unified CM主机、Unified CM Rhosts和Unified CM Sqlhosts文件与发布方匹配。

如果不匹配，则需要重新引导不匹配的节点。如果这些文件不匹配，则不要继续下一步或重置复制。

复制设置

复制无法自动设置，具体取决于版本。要检查此情况，请等待所有服务启动，然后输入utils debreplication runtimestate命令。

状态值0表示正在进行设置，而值2表示已成功为该节点设置复制。

此输出表明复制设置正在进行中(两个节点的状态显示为0):

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

如果任何节点显示状态值为4，或者如果复制在几小时后未成功设置，请从发布方节点输入utils deplication reset all命令。

如果复制继续失败，请参阅排除Linux设备型号Cisco中的CUCM数据库复制故障文章，了解有关如何解决此问题的详细信息。

恢复后

因为数据库恢复不会恢复所有以前的组件，所以必须手动安装或恢复许多服务器级别的项目。

激活服务

DRF恢复不会激活任何服务。导航到工具>服务激活，然后根据统一可维护性页面中的站点文档激活发布者必须运行的所有必要服务：

安装未还原的数据

如果不能进行完全备份，则必须复制某些手动配置。尤其是涉及证书和TFTP功能的配置：

- MoH文件

- 设备包

- 拨号方案(用于非北美编码方案(NANP)拨号)

- 区域设置

- 任何其他杂项缔约方会议文件

- 以前手动上传到发布服务器（如果是TFTP服务器）的所有文件

- 简单网络管理协议(SNMP)社区字符串

- 跨集群分机移动性(EMCC)、集群间位置带宽管理器(LBM)和集群间查找服务(ILS)的批量证书导出

- 安全中继、网关和会议网桥的证书交换

注意：对于混合模式集群，必须再次运行证书信任列表(CTL)客户端。

故障排除

本节介绍可能导致此过程失败的各种方案。

集群不进行身份验证

如果集群不进行身份验证，最常见的两个原因是安全密码不匹配和TCP端口8500上的连接问题。

要验证集群安全密码是否匹配，请在两个节点的CLI中输入utils create report platform命令，并检查platformConfig.xml文件中的哈希值。发布服务器和订用服务器节点上的地址必须匹配。

<IPSecSecurityPwCrypt>

<ParamNameText>Security PW for this node</ParamNameText>

<ParamDefaultValue>password</ParamDefaultValue><ParamValue>0F989713763893AC831812812AB2825C8318

12812AB2825C831812812AB2825C </ParamValue>

</IPSecSecurityPwCrypt>

如果它们匹配，请验证端口8500上的TCP连接。如果它们不匹配，则尝试修复密码时可能会遇到困难，因为CUCM代码中围绕该过程存在一些缺陷：

- 思科漏洞ID CSCtn79868 - pwrecovery工具仅重置sftpuser密码

- Cisco bug ID CSCug92142 - pwrecovery工具不更新内部用户密码

- Cisco bug ID CSCug97360 - pwrecovery实用程序中的selinux denials

- Cisco Bug ID CSCts10778 — 为安全密码恢复过程引发Denials

- Cisco Bug ID CSCua09290 - CLI“set password user security”未设置正确的应用密码

- 思科漏洞ID CSCtx45528 - pwd reset cli返回良好但不会更改密码

- 更改CUCM 10.5上的安全密码后，Cisco Bug ID CSCup30002 — 数据库服务已关闭

- 思科漏洞ID CSCus13276 - CUCM 10.5.2安全密码恢复导致数据库在重新启动时无法启动

如果CUCM版本包含所有这些问题的修复程序，最简单的解决方案是在所有节点上完成Cisco Unified Communications Operating System Administration Guide， Release 10.0(1)中详述的密码恢复过程。

如果CUCM版本不包含这些问题的修复程序，则思科技术支持中心(TAC)可以根据情况执行解决方法。

恢复不处理CCMDB组件

如果恢复未列出数据库组件，则备份本身可能不包含数据库组件。确保发布方数据库运行并且可以接受查询，并执行新的备份。

复制失败

要排除复制故障，请参阅排除Linux设备型号Cisco中的CUCM数据库复制故障文章。

电话未注册或无法访问服务

由于数据库恢复不会恢复任何证书，因此如果发布方是主TFTP服务器，则签名者会有所不同。

如果电话信任订户信任验证服务(TVS)证书，并且电话和TVS服务器之间打开了TCP端口2445，则必须自动解决此问题。

因此，思科建议您维护完整集群DRF备份。

由于Cisco Bug ID CSCtn50405,CUCM 8.6版以前的CUCM版本也可能出现证书问题，即使以前备份成功。

注：有关如何对初始信任列表(ITL)文件进行故障排除的其他信息，请参阅Communications Manager Security Default和ITL Operation and Troubleshooting Cisco文章。