Search <book_title>...

NetBackup™ Snapshot Manager 安装和升级指南

Last Published: 2022-10-28

Product(s): NetBackup (10.1)

Snapshot Manager 故障排除

请参考以下故障排除场景：

如果 Snapshot Manager 代理主机突然重新启动，代理将无法连接到 Snapshot Manager 服务器。
如果安装 Snapshot Manager 代理的主机突然关闭，则可能发生此问题。即使在主机成功重新启动后，代理也无法与 Snapshot Manager 服务器建立连接，之后代理将进入脱机状态。
代理日志文件包含以下错误：
Flexsnap-agent-onhost[4972] mainthread flexsnap.connectors.rabbitmq: error - channel 1 closed unexpectedly: (405) resource_locked - cannot obtain exclusive access to locked queue ' flexsnap-agent.a1f2ac945cd844e393c9876f347bd817' in vhost '/'
出现此问题的原因是，即使在突然关闭代理主机的情况下，代理和 Snapshot Manager 服务器之间的 RabbitMQ 连接也不会关闭。在代理主机错过心跳轮询之前，Snapshot Manager 服务器无法检测到代理不可用。在下一个心跳周期之前，RabbitMQ 连接保持打开状态。如果代理主机在触发下一个心跳轮询之前重新启动，则代理将尝试与 Snapshot Manager 服务器建立新连接。但是，由于之前的 RabbitMQ 连接已存在，新连接尝试将失败，并出现资源已锁定错误。
由于此连接失败，代理将进入脱机状态，并导致在主机上执行的所有快照和还原操作失败。
解决办法：
在代理主机上重新启动 Veritas Snapshot Manager 代理服务。
- 在 Linux 主机上，运行以下命令：
  # sudo systemctl restart flexsnap-agent.service
- 在 Windows 主机上：
  从 Windows 服务控制台重新启动 Veritas Snapshot Manager™ Agent 服务。
Windows 主机上的 Snapshot Manager 代理注册可能会超时或失败。
要保护 Windows 上的应用程序，需要在 Windows 主机上安装并注册 Snapshot Manager 代理。有时，代理注册所花费的时间可能比平时要长、可能超时或失败。
解决办法：
要解决此问题，请尝试执行以下步骤：
- 使用新令牌在 Windows 主机上重新注册代理。
- 如果注册过程再次失败，则在 Snapshot Manager 服务器上重新启动 Snapshot Manager 服务，然后尝试重新注册代理。
有关更多信息，请参考以下内容：
请参见注册基于 Windows 的代理。
请参见重新启动 Snapshot Manager。
DR 软件包丢失或密码丢失时的灾难恢复。
如果 DR 软件包丢失或密码丢失，可能会出现此问题。
如果是目录库备份，则会创建 2 个备份软件包：
- 包含所有证书的 DR 软件包
- 包含数据库的目录库软件包
DR 软件包包含 NetBackup UUID 证书，而目录库 DB 也具有 UUID。当使用 DR 软件包执行灾难恢复并随后执行目录库恢复时，将同时还原 UUID 证书和 UUID。这样 NetBackup 便可以与 Snapshot Manager 进行通信，因为未更改 UUID。
但是，如果 DR 软件包丢失或密码丢失，则无法完成 DR 操作。没有 DR 软件包的情况下，只有重新安装 NetBackup 后才能恢复目录库。在这种情况下，将为 NetBackup 创建一个不被 Snapshot Manager 识别的新 UUID。NetBackup 与 Snapshot Manager 的一对一映射将丢失。
解决办法：
要解决此问题，必须在创建 NetBackup 主服务器后更新该新 NBU UUID 和版本号。
- NetBackup 管理员必须登录 NetBackup Web 管理服务，才能执行此任务。使用以下命令登录：
  /usr/openv/netbackup/bin/bpnbat -login -loginType WEB
- 在主服务器上执行以下命令获取 NBU UUID：
  /usr/openv/netbackup/bin/admincmd/nbhostmgmt -list -host <primary server host name> | grep "Host ID"
- 执行以下命令获取版本号：
  /usr/openv/netbackup/bin/admincmd/bpgetconfig -g <primary Ssrver host name> -L
获取 NBU UUID 和版本号后，请在 Snapshot Manager 主机上执行以下命令更新映射：
/cloudpoint/scripts/cp_update_nbuuid.sh -i <NBU UUID> -v <Version Number>
快照作业成功，但在主服务器上禁用 ECA_CRL_CHECK 时，备份作业失败并显示错误“Snapshot Manager 证书无效或不存在。(9866)”。
如果 ECA_CRL_CHECK 已在主服务器上进行配置且处于禁用状态，则必须在 Snapshot Manager 设置的 bp.conf 中以相同的值配置它。
例如，考虑从快照备份的情况，其中 NetBackup 配置了外部证书且证书已吊销。在这种情况下，如果在主服务器上将 ECA_CRL_CHECK 设置为 DISABLE，则在 Snapshot Manager 设置的 bp.conf 中设置相同的值，否则快照操作将成功，但备份操作将失败并显示证书错误。
请参见为 Azure Stack 配置安全性。
Snapshot Manager 无法使用无代理连接到 Windows 云实例
错误 1：<Instance_name>: network connection timed out.
案例 1：Snapshot Manager 服务器日志消息：
```
WARNING - Cannot connect to the remote host. SMB Connection timeout
 <IP address> <user>

…

flexsnap.OperationFailed: Could not connect to the remote server 
<IP address>
```
解决办法：
要解决此问题，请尝试执行以下步骤：
- 验证 SMB 端口 445 是否已添加到网络安全组中，以及是否可从 Snapshot Manager 进行访问。
- 验证是否允许 SMB 端口 445 通过云实例防火墙。
案例 2：Snapshot Manager 日志消息：
```
WARNING - Cannot connect to the remote host. WMI Connection 
timeout <IP address> <user>

…

flexsnap.OperationFailed: Could not connect to the remote 
server <IP address>
```
解决办法：
要解决此问题，请尝试执行以下步骤：
- 验证是否已在网络安全组中添加 DCOM 端口 (135) 以及是否可从 Snapshot Manager 进行访问。
- 验证是否允许端口 135 通过云实例防火墙。
案例 3：Snapshot Manager 日志消息：
```
Exception while opening SMB connection, [Errno Connection error 
(<IP address>:445)] [Errno 113] No route to host.
```
解决办法：验证云实例是否已启动且正在运行，或者是否处于不一致状态。
案例 4：Snapshot Manager 日志消息：
```
Error when closing dcom connection: 'Thread-xxxx'"
```
其中，xxxx 是线程编号。
解决办法：
要解决此问题，请尝试执行以下步骤：
- 验证 WMI-IN 动态端口范围或配置的固定端口是否已添加到网络安全组中。
- 从云实例防火墙验证并启用 WMI-IN 端口。
错误 2：<Instance_name>: Could not connect to the virtual machine.
Snapshot Manager 日志消息：
```
Error: Cannot connect to the remote host. <IP address> Access denied. 
```
解决办法：
要解决此问题，请尝试执行以下步骤：
- 验证用户是否具有管理权限。
- 验证是否为用户禁用了 UAC。
如果禁用了防火墙，则 RHEL 系统上的 Snapshot Manager 云操作将失败
如果运行 Snapshot Manager 服务时在该系统上禁用了防火墙，则 RHEL 系统上所有受支持的云插件的 Snapshot Manager 操作都会失败。这是网络配置问题，会阻止 Snapshot Manager 访问云提供商 REST API 端点。
解决办法：
- 停止 Snapshot Manager
  # docker run --rm -it
  -v /var/run/docker.sock:/var/run/docker.sock
  -v /cloudpoint:/cloudpoint veritas/flexsnap-deploy:<version> stop
- 重新启动 Docker
  # systemctl restart docker
- 重新启动 Snapshot Manager
  # docker run --rm -it
  -v /var/run/docker.sock:/var/run/docker.sock
  -v /cloudpoint:/cloudpoint veritas/flexsnap-deploy:<version> start

从快照备份作业和索引作业失败并出现错误

Jun 10, 2021 2:17:48 PM - Error mqclient (pid=1054) SSL
Connection failed with string, broker:<hostname>
Jun 10, 2021 2:17:48 PM - Error mqclient (pid=1054) Failed SSL
handshake, broker:<hostname>
Jun 10, 2021 2:19:16 PM - Error nbcs (pid=29079) Invalid
operation for asset: <asset_id>
Jun 10, 2021 2:19:16 PM - Error nbcs (pid=29079) Acknowledgement
not received for datamover <datamover_id>

和/或

Jun 10, 2021 3:06:13 PM - Critical bpbrm (pid=32373) from client
<asset_id>: FTL - Cannot retrieve the exported snapshot details
for the disk with UUID:<disk_asset_id>
Jun 10, 2021 3:06:13 PM - Info bptm (pid=32582) waited for full
buffer 1 times, delayed 220 times
Jun 10, 2021 3:06:13 PM - Critical bpbrm (pid=32373) from client
<asset_id>: FTL - cleanup() failed, status 6

在操作系统防火墙级别 (firewalld) 阻止通过端口 5671 和 443 对 Snapshot Manager 进行入站访问时，可能会发生这种情况。因此，在 datamover 容器（用于从快照备份和索引作业）中，与 Snapshot Manager 的通信将被阻止。这导致 datamover 容器无法启动备份或索引。

解决办法：

修改操作系统防火墙中的规则，以允许来自 5671 和 443 端口的入站连接。

VM 的无代理连接失败，并显示错误消息。
如果用户通过门户将 VM 的身份验证类型从基于 SSH 密钥更改为基于密码，则 VM 的无代理连接将失败，并显示以下错误消息：
```
User does not have the required privileges to establish an agentless connection
```
如上述错误消息中所述，如果未在 sudoers 文件中为用户正确定义权限，则会出现此问题。
解决办法：
通过提供执行无密码 sudo 操作所需的权限来解决用户的 sudoers 文件问题。
在专用子网（无 Internet）中部署 Snapshot Manager 时，Snapshot Manager 功能失败
当 Snapshot Manager 部署在已启用防火墙或已禁用公用 IP 的专用网络中时，会发生此问题。客户的信息安全团队不允许对该虚拟机进行完全 Internet 访问。
解决办法：
使用以下命令从防火墙命令行启用端口：
firewall-cmd --add-port=22/tcp
firewall-cmd --add-port=5671/tcp
firewall-cmd --add-port=443/tcp
从备份副本还原资产失败
在某些情况下，用户发现 Docker 容器中的连接会间歇性地重置。因此，服务器发送的 tcp 负载比客户端通知窗口要多。有时，Docker 容器会从新的 TCP 连接握手中丢弃 SYN+ACK 数据包。要允许这些数据包，请使用 nf_conntrack_tcp_be_liberal 选项。
如果 nf_conntrack_tcp_be_liberal = 1，则允许以下数据包：
- ACK 低于下限（可能已过度延迟 ACK）
- ACK 高于上限（尚未看到 ACK 数据）
- SEQ 低于下限（已重新传输 ACK 数据）
- SEQ 高于上限（超过接收器窗口）
如果 nf_conntrack_tcp_be_liberal = 0，则这些数据包也会被视为无效而遭到拒绝。
解决办法：
要解决从备份副本还原的问题，请使用 nf_conntrack_tcp_be_liberal = 1 选项，并在运行 datamover 容器的节点上设置此值。
使用以下命令设置 nf_conntrack_tcp_be_liberal 的值：
sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal=1
Kubernetes 扩展上的某些 pod 推进到已完成状态
解决办法：
禁用 Kubernetes 扩展。
使用以下命令删除侦听程序 pod：
#kubectl delete pod flexnsap-listener-xxxxx -n <namespace>
启用 Kubernetes 扩展。
用户无法自定义云保护计划
解决办法：
使用所需配置创建新的保护计划，然后将其分配给资产。
Podman 容器未启动或容器在重新启动后不运行
在 RHEL 8.x 平台上，重新启动容器或计算机重新启动时，容器将显示以下错误消息：
```
# podman restart flexsnap-coordinator 47ca97002e53de808cb8d0526ae033d4b317d5386ce085a8bce4cd434264afdf:
 "2022-02-05T04:53:42.265084989+00:00 Feb 05 04:53:42 flexsnap-coordinator flexsnap-coordinator[7] 
agent_container_health_check flexsnap.container_manager: INFO - Response: b'{""cause"":""that name is already in use"",""message"":
""error creating container storage: the container name \\""flexsnap-agent.15bd0aea11164f7ba29e944115001d69\\"" is already in use by 
\\""30f031d586b1ab524511601aad521014380752fb127a9440de86a81b327b6777\\"". You have to remove that container to be able to reuse that
 name.: that name is already in use"",""response"":500}\n'"
```
解决办法：
检查是否有一个文件的 IP 地址条目映射到无法在 /var/lib/cni/network/flexsnap-network/ 文件系统位置启动的容器。
[ec2-user@ip-172-31-44-163 ~]$ ls -latr /var/lib/cni/networks/flexsnap-network/ total 16 -rwxr-x---. 1 root root 0 Jan 22 12:30 lock drwxr-xr-x. 4 root root 44 Jan 22 12:30 .. -rw-r--r--. 1 root root 70 Feb 4 14:47 10.89.0.150 -rw-r--r--. 1 root root 70 Feb 4 14:47 10.89.0.151 -rw-r--r--. 1 root root 70 Feb 4 14:47 10.89.0.152 -rw-r--r--. 1 root root 11 Feb 7 11:09 last_reserved_ip.0 drwxr-xr-x. 2 root root 101 Feb 7 11:13 . [ec2-user@ip-172-31-44-163 ~]$
从上述目录中，删除重复的 IP 地址文件并执行停止和启动操作，如下所示：
停止容器：#podman stop <container_name>
启动容器：#podman start <container_name>

启动“启动/停止”服务后，Snapshot Manager、RabbitMQ 和 MongoDB 容器仍处于启动状态

据观察，flexsnap-mongodb 和 flexsnap-rabbitmq 容器未进入正常运行状态。以下是 flexsnap-mongodb 容器的状态：

[ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='{{json .Config.Healthcheck}}'
flexsnap-mongodb {"Test":["CMD-SHELL","echo 'db.runCommand({ping: 1}).ok' 
| mongo --ssl --sslCAFile /cloudpoint/keys/cacert.pem 
--sslPEMKeyFile /cloudpoint/keys/mongodb.pem flexsnap-mongodb:27017/zenbrain --quiet"],
"Interval":60,"Timeout":30000000000,"Retries":3} [ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='
{{json .State.Healthcheck}}' flexsnap-mongodb {"Status":"starting","FailingStreak":0,"Log":null} [ec2-user@ip-172-31-23-60 log]$

解决办法：

运行以下 #podman CLI 命令：

[ec2-user@ip-172-31-23-60 log]$ sudo podman healthcheck run flexsnap-mongodb

[ec2-user@ip-172-31-23-60 log]$ sudo podman ps -a

CONTAINER ID  IMAGE                          COMMAND  CREATED      STATUS                  PORTS                      NAMES

fe8cf001032b  localhost/veritas/

  flexsnap-fluentd:10.0.0.0.9817         2 days ago    Up 45 hours ago      0.0.0.0:24224->24224/tcp  flexsnap-fluentd

2c00500c1ac6  localhost/veritas/

  flexsnap-mongodb:10.0.0.0.9817         2 days ago    Up 45 hours ago (healthy)                      flexsnap-mongodb

7ab3e248024a  localhost/veritas/

  flexsnap-rabbitmq:10.0.0.0.9817        2 days ago    Up 45 hours ago (starting)                     flexsnap-rabbitmq

[ec2-user@ip-172-31-23-60 log]$ sudo podman healthcheck run flexsnap-rabbitmq

[ec2-user@ip-172-31-23-60 log]$ sudo podman ps -a

CONTAINER ID  IMAGE                           COMMAND  CREATED       STATUS                   PORTS                   NAMES

fe8cf001032b  localhost/veritas/

  flexsnap-fluentd:10.0.0.0.9817        2 days ago    Up 45 hours ago          0.0.0.0:24224->24224/tcp  flexsnap-fluentd

2c00500c1ac6  localhost/veritas/

  flexsnap-mongodb:10.0.0.0.9817        2 days ago    Up 45 hours ago (healthy)                          flexsnap-mongodb

7ab3e248024a  localhost/veritas/

  flexsnap-rabbitmq:10.0.0.0.9817       2 days ago    Up 45 hours ago (healthy)                          flexsnap-rabbitmq

 [ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='{{json .State.Healthcheck}}' flexsnap-mongodb

{"Status":"healthy","FailingStreak":0,"Log":

[{"Start":"2022-02-14T07:32:13.051150432Z","End":"2022-02-14T07:32:13.444636429Z","ExitCode":0,"Output":""}]}

[ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='{{json .State.Healthcheck}}' flexsnap-rabbitmq

{"Status":"healthy","FailingStreak":0,"Log":

[{"Start":"2022-02-14T07:32:46.537804403Z","End":"2022-02-14T07:32:47.293695744Z","ExitCode":0,"Output":""}]}

[ec2-user@ip-172-31-23-60 log]$

向 NetBackup 注册 Snapshot Manager 时，证书生成将失败
从 Snapshot Manager 版本 9.1.2 开始，NetBackup 证书生成将与 Snapshot Manager 注册 API 中的注册操作同步进行。因此，在向 NetBackup 注册 Snapshot Manager 时，即在 Web UI 中添加或编辑 Snapshot Manager 条目时，任何证书生成失败都会导致注册失败。这些证书用于 datamover，而 datamover 启动后用于从快照备份、从备份还原、索引编制（基于 VxMS）等操作。因此，如果证书生成失败，则无法执行这些作业。所以，云 VM 上的 Snapshot Manager 无法连接到实验室 VM 上的 NetBackup，因而注册将失败，Snapshot Manager 也无法添加到 NetBackup。
解决办法：
要在此类情况下添加 Snapshot Manager，需要在 /cloudpoint/flexsnap.conf 文件中添加以下条目，跳过 Snapshot Manager 上的证书生成：
[client_registration] skip_certificate_generation = yes
6 小时的默认超时不允许还原更大的数据库（大小超过 300 GB）
解决办法：
可以将可配置的超时参数值设置为还原更大的数据库。可以在 flexsnap-coordinator 容器的 /etc/flexsnap.conf 文件中指定超时值。这不需要重新启动协调器容器。在下一个数据库还原作业中将会选取超时值。
用户必须按如下所示指定超时值（以秒为单位）：
docker exec -it flexsnap-coordinator bash root@flexsnap-coordinator:/# cat /etc/flexsnap.conf [global] target = flexsnap-rabbitmq grt_timeout = 39600
如果从备份中还原的 VM 附加了 50 个标记，则到已还原主机的无代理连接和粒度还原将失败
解决办法：
（对于 AWS）如果从备份中还原的 Windows VM 具有 50 个标记，且平台标记不存在，则用户可以删除任何不需要的标记，并添加 Platform: windows 标记。

对于 GKE 版本的少数版本，在命名空间中观察到了失败的 pod 问题

下面是在命名空间中观察到的几个失败的 pod，失败状态为 NodeAffinity：

$ kubectl get pods -n <cp_extension_namespace>

NAME                                        READY     STATUS       RESTARTS     AGE
flexsnap-datamover-
2fc2967943ba4ded8ef653318107f49c-664tm        0/1     Terminating    0          4d14h
flexsnap-fluentd-collector-c88f8449c-5jkqh    0/1     NodeAffinity   0          3d15h
flexsnap-fluentd-collector-c88f8449c-ph8mx    0/1     NodeAffinity   0          39h
flexsnap-fluentd-collector-c88f8449c-rqw7w    1/1     Running        0          10h
flexsnap-fluentd-collector-c88f8449c-sswzr    0/1     NodeAffinity   0          5d18h
flexsnap-fluentd-ftlnv                        1/1     Running        3 (10h ago)10h
flexsnap-listener-84c66dd4b8-6l4zj            1/1     Running        0          10h
flexsnap-listener-84c66dd4b8-ls4nb            0/1     NodeAffinity   0          17h
flexsnap-listener-84c66dd4b8-x84q8            0/1     NodeAffinity   0          3d15h
flexsnap-listener-84c66dd4b8-z7d5m            0/1     NodeAffinity   0          5d18h
flexsnap-operator-6b7dd6c56c-cf4pc            1/1     Running        0          10h
flexsnap-operator-6b7dd6c56c-qjsbs            0/1     NodeAffinity   0          5d18h
flexsnap-operator-6b7dd6c56c-xcsgj            0/1     NodeAffinity   0          3d15h
flexsnap-operator-6b7dd6c56c-z86tc            0/1     NodeAffinity   0          39h

但是，这些失败不会影响 Snapshot Manager Kubernetes 扩展的功能。

解决办法：

使用以下命令手动清理失败的 pod：

kubectl get pods -n <cp_extension_namespace> | grep NodeAffinity | awk '{print $1}' | xargs kubectl delete pod -n <cp_extension_namespace>

如果在以前的尝试中 Snapshot Manager 注册失败，则插件信息重复

仅当使用 MarketPlace 部署机制部署 Snapshot Manager 时，才会发生这种情况。在注册之前添加插件信息时，会出现此问题。此问题会在 CloudPoint_plugin.conf 文件中创建重复的插件信息。

解决办法：

从 CloudPoint_plugin.conf 文件中手动删除重复的插件信息。

例如，考虑以下示例，在 CloudPoint_plugin.conf 文件中可以看到重复的 GCP 插件配置条目（粗体）：

{
    "CPServer1": [
      {
        "Plugin_ID": "test",
        "Plugin_Type": "aws",
        "Config_ID": "aws.8dda1bf5-5ead-4d05-912a-71bdc13f55c4",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  },
  {
    "CPServer2": [
      {
        "Plugin_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Type": "gcp",
        "Config_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Category": "Cloud",
        "Disabled": false
      },
      {
        "Plugin_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Type": "gcp",
        "Config_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  }

如果克隆的 Snapshot Manager 添加到了 NetBackup 中，则插件信息重复

仅当在 Snapshot Manager 迁移到 RHEL 8.6 VM 期间将克隆的 Snapshot Manager 添加到了 NetBackup 中时，才会发生这种情况。Snapshot Manager 的克隆操作使用现有的 Snapshot Manager 卷来创建新 Snapshot Manager。这会在 CloudPoint_plugin.conf 文件中创建重复的条目。

解决办法：

从 CloudPoint_plugin.conf 文件中手动编辑和删除重复的插件信息。

例如，考虑以下示例，在 CloudPoint_plugin.conf 文件中可以看到重复的 Azure 插件配置条目（粗体）：

{
    "CPServer1": [
      {
        "Plugin_ID": "config10",
        "Plugin_Type": "azure",
        "Config_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  },
  {
    "CPServer2": [
      {
        "Plugin_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Type": "azure",
        "Config_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Category": "Cloud",
        "Disabled": false
      },
       {
    "cpserver101.yogesh.joshi2-dns-zone": [
      {
        "Plugin_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Type": "azure",
        "Config_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Category": "Cloud",
        "Disabled": false
      },
      {
        "Plugin_ID": "AZURE_PLUGIN",
        "Plugin_Type": "azure",
        "Config_ID": "azure.4400a00a-8d2b-4985-854a-74f48cd4567e",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  }
 ]
}