NetBackup™ Snapshot Manager for Cloud 安装和升级指南

如果 NetBackup Snapshot Manager 代理主机突然重新启动，代理将无法连接到 NetBackup Snapshot Manager 服务器。

如果安装 NetBackup Snapshot Manager 代理的主机突然关闭，则可能发生此问题。即使在主机成功重新启动后，代理也无法与 NetBackup 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 '/'

出现此问题的原因是，即使在突然关闭代理主机的情况下，代理和 NetBackup Snapshot Manager 服务器之间的 RabbitMQ 连接也不会关闭。在代理主机错过心跳轮询之前，NetBackup Snapshot Manager 服务器无法检测到代理不可用。在下一个心跳周期之前，RabbitMQ 连接保持打开状态。如果代理主机在触发下一个心跳轮询之前重新启动，则代理将尝试与 NetBackup Snapshot Manager 服务器建立新连接。但是，由于之前的 RabbitMQ 连接已存在，新连接尝试将失败，并出现资源已锁定错误。

由于此连接失败，代理将进入脱机状态，并导致在主机上执行的所有快照和还原操作失败。

解决办法：

在代理主机上重新启动 Veritas NetBackup Snapshot Manager 代理服务。

Windows 主机上的 NetBackup Snapshot Manager 代理注册可能会超时或失败。

要保护 Windows 上的应用程序，需要在 Windows 主机上安装并注册 NetBackup Snapshot Manager 代理。有时，代理注册所花费的时间可能比平时要长、可能超时或失败。

解决办法：

要解决此问题，请尝试执行以下步骤：

有关更多信息，请参考以下内容：

请参见注册基于 Windows 的代理。

请参见重新启动 NetBackup Snapshot Manager。

DR 软件包丢失或密码丢失时的灾难恢复。

如果 DR 软件包丢失或密码丢失，可能会出现此问题。

如果是目录库备份，则会创建 2 个备份软件包：

DR 软件包包含 NetBackup UUID 证书，而目录库 DB 也具有 UUID。当使用 DR 软件包执行灾难恢复并随后执行目录库恢复时，将同时还原 UUID 证书和 UUID。这样 NetBackup 便可以与 NetBackup Snapshot Manager 进行通信，因为未更改 UUID。

但是，如果 DR 软件包丢失或密码丢失，则无法完成 DR 操作。没有 DR 软件包的情况下，只有重新安装 NetBackup 后才能恢复目录库。在这种情况下，将为 NetBackup 创建一个不被 NetBackup Snapshot Manager 识别的新 UUID。NetBackup 与 NetBackup Snapshot Manager 的一对一映射将丢失。

解决办法：

要解决此问题，必须在创建 NetBackup 主服务器后更新该新 NBU UUID 和版本号。

获取 NBU UUID 和版本号后，请在 NetBackup Snapshot Manager 主机上执行以下命令更新映射：

/cloudpoint/scripts/cp_update_nbuuid.sh -i <NBU UUID> -v <Version Number>

快照作业成功，但在主服务器上禁用 ECA_CRL_CHECK 时，备份作业失败并显示错误“NetBackup Snapshot Manager 证书无效或不存在。(9866)”。

如果 ECA_CRL_CHECK 已在主服务器上进行配置且处于禁用状态，则必须在 NetBackup Snapshot Manager 设置的 bp.conf 中以相同的值配置它。

例如，考虑从快照备份的情况，其中 NetBackup 配置了外部证书且证书已吊销。在这种情况下，如果在主服务器上将 ECA_CRL_CHECK 设置为 DISABLE，则在 NetBackup Snapshot Manager 设置的 bp.conf 中设置相同的值，否则快照操作将成功，但备份操作将失败并显示证书错误。

请参见为 Azure Stack 配置安全性 。

如果禁用了防火墙，则 RHEL 系统上的 NetBackup Snapshot Manager 云操作将失败

如果运行 NetBackup Snapshot Manager 服务时在该系统上禁用了防火墙，则 RHEL 系统上所有受支持的云插件的 NetBackup Snapshot Manager 操作都会失败。这是网络配置问题，会阻止 NetBackup Snapshot Manager 访问云提供商 REST API 端点。

解决办法：

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

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 对 NetBackup Snapshot Manager 进行入站访问时，可能会发生这种情况。因此，在 datamover 容器（用于从快照备份和索引作业）中，与 NetBackup 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）中部署 NetBackup Snapshot Manager 时，NetBackup Snapshot Manager 功能失败

当 NetBackup 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，则允许以下数据包：

如果 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 扩展。

用户无法自定义云保护计划

解决办法：

使用所需配置创建新的保护计划，然后将其分配给资产。

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

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

解决办法：

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

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

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

仅当使用 MarketPlace 部署机制部署 NetBackup 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
      }
    ]
  }

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

仅当在 NetBackup Snapshot Manager 迁移到 RHEL 8.6 VM 期间将克隆的 NetBackup Snapshot Manager 添加到了 NetBackup 中时，才会发生这种情况。NetBackup Snapshot Manager 的克隆操作使用现有的 NetBackup Snapshot Manager 卷来创建新 NetBackup 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
      }
    ]
  }
 ]
}

由于 SSL 证书错误，使用 Azure 中部署的 Snapshot Manager 10.0 版执行从快照备份操作失败

由于与 CRL (curl) 相关的 SSL 证书错误，使用 Azure 中部署的 Snapshot Manager 10.3 或更高版本执行从快照备份操作失败。

解决办法：

在 Snapshot Manager bp.conf 文件中添加 ECA_CRL_CHECK = 0 并确保可以从介质服务器访问 Azure 端点。