NetBackup™ Web UI 云管理指南
对 PaaS 工作负载保护和恢复问题进行故障排除
可以在活动监视器中看到以下消息:
授权失败 - 消息:客户端 '<clientId> '<objetId>' 无权对范围 '<resoourceId>' 执行操作 'Microsoft.Sql/servers/databases/read',或者范围无效。如果最近为您授予了访问权限,请刷新您的凭据。
解释:在以下情况下会出现此错误:Snapshot Manager 和 NetBackup 部署在 AKS 中,并且:
介质服务器 pod 节点池是与 Snapshot Manager 节点池不同的节点池
在 Snapshot Manager 虚拟机扩展集中启用了托管标识
解决办法:执行以下任一操作:
在用于备份和还原的介质服务器中,在扩展集中启用托管标识。此外,在附加到此托管标识的角色中分配所需权限。
在 MSDP 服务器上创建存储单元,并仅使用在扩展配置中启用了托管标识的介质服务器。
解释:如果将只读锁定或删除锁定属性应用于数据库或资源组,则会发生此问题。
解决办法:在执行任何备份或还原之前,从数据库或资源组中删除任何现有的只读锁定和删除锁定属性。
解释:从活动监视器手动取消备份或还原作业且在部分还原操作期间于门户上创建了数据库时,会出现此错误。
解决办法:手动清理提供商门户上的数据库,以及通过数据库名称创建的特定目录下通用共享装入位置处的临时暂存位置。
解释:如果 Snapshot Manager 容器服务突然重新启动,受提供商保护的还原作业可能保持活动状态,您可能无法在活动监视器详细信息页面上看到更新的状态。
解决办法:在 Snapshot Manager 中使用以下命令重新启动工作流程容器:
docker restart flexsnap-workflow-system-0-min flexsnap-workflow-general-0-min
重新启动容器后,还原作业将在活动监视器中更新为最新状态。
解释: 如果用于备份的客户端名称长度超过 255 个字符,则会显示此错误。
bpdbm 日志通过显示以下错误消息来确认此错误:
db_error_add_to_file: Length of client is too long. Got 278, but limit is 255. read_next_image: db_IMAGEreceive() failed: text exceeded allowed length (225)
注意:
当主服务器是 RHEL 时,会出现此错误。
解决办法:重命名数据库,使客户端名称适合 255 个字符的长度。
解释:如果使用的客户端名称较长,则在备份期间会发生此错误,由于此目录库映像的文件路径长度超过 256 个字符,因此会失败并在活动监视器中显示上述错误消息。
bpdbm 日志通过显示以下错误消息来确认此错误:
<16> db_error_add_to_file: cannot stat(\\?\C:\Program Files\Veritas \NetBackup\db\images \azure-midb-1afb87487dc04ddc8fafe453dccb7ca3+ nbux-qa-bidi-rg+eastus+az-sql-mi-bidinet01+ testdb_bidinet02\1656000000\tmp\catstore\ BACKUPNOW+141a73e7-cdc4-4371-823a-f170447dba2d_ 1656349831_FULL.f_imgUserGroupNames0): No such file or directory (2) <16> ImageReadFilesFile::get_file_size: cannot stat(\\?\C:\Program Files\Veritas\NetBackup\db \images\azure-midb-1afb87487dc04ddc8fafe453d ccb7ca3+nbux-qa-bidi-rg+eastus+az-sql-mi-bidinet01+testdb_ bidinet02\1656000000\tmp\catstore\BACKUPNOW+141a73e7-cdc4-4371 -823a-f170447dba2d_1656349831_FULL.f_imgUserGroupNames0): No such file or directory (2) <16> ImageReadFilesFile::executeQuery: Cannot copy \\?\C:\Program Files\Veritas\NetBackup\db\images\azure-midb-1afb87487dc04ddc8fafe453dccb7 ca3+nbux-qa-bidi-rg+eastus+az-sql-mi-bidinet01+testdb_bidinet02\1 656000000\tmp\catstore\BACKUPNOW+141a73e7-cdc4-4371-823a-f170447d ba2d_1656349831_FULL.f_imgUserGroupNames0
注意:
当主服务器是 Windows 时,会出现此错误。
解决办法:重命名数据库,使文件路径长度适合 256 个字符的长度。
解释:NetBackup 无法成功执行请求的操作。
建议的操作:有关可能的失败原因,请参考活动监视器详细信息。
解释:dbagentsutil 日志中显示的错误消息为 pg_dump: error: query failed: ERROR: permission denied for table test;pg_dump: error: query was: LOCK TABLE public.test IN ACCESS SHARE MODE;Invoked operation: PRE_BACKUP failed
如果尝试备份的数据库包含多个具有不同角色的表,则会发生这种情况。如果表有至少一个除数据库所有者之外的其他所有者,并且它不是数据库所有者角色的成员,则备份可能会失败。
推荐的操作:必须具有一个角色,该角色有权访问要备份或还原的数据库中的所有表。
例如,我们想备份包含两个表的 School 数据库。
对于
student表,所有者是postgres对于
teacher表,所有者是schooladmin
创建新角色。比如说,NBUbackupadmin
运行以下命令以创建角色:
postgres=> CREATE USER NBUbackupadmin WITH PASSWORD '***********';
CREATE ROLE
要使此新角色成为 postgres 和 schooladmin 角色的成员,请运行:
postgres=> GRANT postgres TO NBUbackupadmin;
GRANT ROLE
postgres=> GRANT schooladmin TO NBUbackupadmin;
GRANT ROLE
注意:
对于数据库中的所有表,您必须具有一个角色,该角色是表的所有者或所有者的成员。
解释:由于与介质服务器的连接断开,备份失败。
推荐的操作:如果策略启用了检查点,则可以重新启动备份作业。解决网络问题后,在 Web UI 中选择未完成的备份作业,然后单击。作业将从停止的点继续。如果策略中未启用检查点,则作业在 Web UI 中显示为失败的作业。