Please enter search query.
Search <book_title>...
NetBackup™ 重复数据删除指南
Last Published:
2025-04-24
Product(s):
NetBackup & Alta Data Protection (11.0)
- NetBackup 介质服务器重复数据删除选件简介
- 规划部署
- 关于 MSDP 存储和连接要求
- 关于 NetBackup 介质服务器重复数据删除
- 关于 NetBackup Client Direct 重复数据删除
- 关于 MSDP 远程办公客户端重复数据删除
- 关于 MSDP 流处理程序
- MSDP 部署最佳做法
- 置备存储
- 配置重复数据删除
- 关于 MSDP 重复数据删除多线程代理
- 关于 MSDP 指纹识别
- 启用对 400 TB MSDP 的支持
- 为介质服务器重复数据删除池配置存储服务器
- 关于 NetBackup 重复数据删除的磁盘池
- 配置介质服务器重复数据删除池存储单元
- 为 MSDP 客户端重复数据删除配置客户端属性
- 关于 MSDP 加密
- 关于使用 NetBackup 密钥管理服务器服务进行 MSDP 加密
- 关于用于 MSDP 复制和同步复制的单独网络路径
- 关于同一域内的 MSDP 优化复制
- 配置以不同 NetBackup 域为目标的 MSDP 复制
- 关于存储生命周期策略
- “弹性网络”属性
- 关于 NetBackup 客户端上的可变长度重复数据删除
- 关于 MSDP pd.conf 配置文件
- 关于保存 MSDP 存储服务器配置
- 关于保护 MSDP 目录库
- 关于 NetBackup WORM 存储对不可变和不可删除数据的支持
- 使用非 root 用户运行 MSDP 服务
- 使用非 root 用户运行 MSDP 命令
- MSDP 卷组 (MVG)
- MSDP 云支持
- 关于 MSDP 云支持
- 云空间回收
- 关于云 LSU 的灾难恢复
- 关于使用 MSDP 云的映像共享
- 关于 MSDP 云不可篡改的 (WORM) 存储支持
- 关于 AWS IAM Role Anywhere 支持
- 关于 Azure 服务主体支持
- 关于 NetBackup 对 AWS Snowball Edge 的支持
- 关于云直连
- MSDP S3 接口
- 监视重复数据删除活动
- 管理重复数据删除
- 管理 MSDP 服务器
- 管理 NetBackup 重复数据删除引擎凭据
- 管理介质服务器重复数据删除池
- 关于 MSDP 数据完整性检查
- 关于 MSDP 存储基址重置
- 恢复 MSDP
- 替换 MSDP 主机
- 卸载 MSDP
- 重复数据删除体系结构
- 配置和管理通用共享
- 配置隔离恢复环境 (IRE)
- 使用 NetBackup 重复数据删除 Shell
- 从重复数据删除 shell 管理用户
- 关于外部 MSDP 目录库备份
- 从重复数据删除 shell 管理证书
- 从重复数据删除 shell 管理 NetBackup 服务
- 从重复数据删除 shell 监控 NetBackup 服务并对其进行故障排除
- 从重复数据删除 shell 管理 S3 服务
- 故障排除
- 附录 A. 迁移到 MSDP 存储
- 附录 B. 从 Cloud Catalyst 迁移到 MSDP 直接云分层
- 附录 C. Encryption Crawler
从失败的迁移恢复到 Cloud Catalyst
无论迁移成功还是失败,通过恢复 NetBackup 主服务器目录库来恢复到 Cloud Catalyst 都是最安全的方法。但是,在不恢复主服务器目录库的情况下,在迁移失败后或许可以恢复到 Cloud Catalyst。
如果出现故障且在显示以下消息之前 nbdecommission 命令退出,或许可以在不恢复主服务器目录库的情况下恢复到 Cloud Catalyst。以下消息显示在命令输出中或 nbdecommission 命令的 admin
日志文件中:
Disk pool <new disk pool name> has been successfully created with 1 volumes
如果在显示磁盘池
消息后迁移失败,则需要恢复主服务器目录库才能恢复到 Cloud Catalyst。
如果不恢复主服务器目录库,则必须手动删除新磁盘池、磁盘卷、云存储服务器和 MSDP 云层服务器。恢复到 Cloud Catalyst 后,必须删除上述各项。
以下过程假设在输出中显示 Disk pool 消息之前,迁移失败。该过程还假定 Cloud Catalyst 服务器不重新用作迁移的 MSDP 云层服务器。
迁移失败后恢复到 Cloud Catalyst
- 停止新 MSDP 云层服务器上的 NetBackup 服务。
- 在 Cloud Catalyst 服务器上,确保
esfs.json
文件的 ReadOnly 已设置为 0。如果只需执行还原,不打算运行到 Cloud Catalyst 的新备份或复制作业,则将 ReadOnly 设置为 1。
- 在 Cloud Catalyst 服务器上启动 NetBackup 服务。
- Cloud Catalyst 存储服务器联机后,您可以继续执行还原、备份或优化复制作业。
备份或优化复制作业要求在
esfs.json
文件中将 ReadOnly 设置为 0。 - 如果运行 Cloud Catalyst 版本 8.2 或更低版本,您可能需要为介质服务器部署基于主机名的新证书。可通过在主服务器上运行以下命令来部署该证书:
/usr/openv/netbackup/bin/admincmd/bpnbaz –ProvisionCert <CloudCatalyst host-name>
必须在 Cloud Catalyst 服务器上重新启动 NetBackup 服务。
- 您可能需要运行以下命令,以允许 Cloud Catalyst 从云存储的存储桶中读取数据:
/usr/openv/esfs/bin/setlsu_ioctl <cachedir>/storage/proc/cloud.lsu <bucketname>
如果在不需要时运行此命令,也不会有负面影响。如果运行该命令,则会看到以下输出:
return code: -1 File exists.
- (可选)删除云存储中的整个 MSDP 云子存储桶文件夹,以避免浪费空间,并避免未来迁移到 MSDP 云层服务器时出现任何问题。
以下过程假定在重新用作和/或重新安装为 MSDP 云层服务器的 Cloud Catalyst 服务器上,迁移失败。
重新使用 Cloud Catalyst 服务器时,迁移失败后恢复到 Cloud Catalyst
- 停止新 MSDP 云层服务器上的 NetBackup 服务。
- 使用在执行迁移时处于活动状态的同一 NetBackup 版本和 EEB 捆绑软件包重新安装 Cloud Catalyst 服务器。
- 然后联系 Cohesity 技术支持,按 rebuild_esfs 过程从云存储中的数据恢复该 Cloud Catalyst 服务器。(rebuild_esfs 过程取代了恢复 Cloud Catalyst 服务器的旧 drcontrol 方法。drcontrol 方法已弃用。)
- (可选)删除云存储中的整个 MSDP 云子存储桶文件夹,以避免浪费空间,并避免未来迁移到 MSDP 云层服务器时出现任何问题。