控制台相关问题

如果您有两台虚拟机（VM1 和 VM2），它们在 ESXi 主机中具有相同的 GUID ，并且这两台 VM 分别由不同 vCenter（VC1 和 VC2）管理。您将 VM1 导入到控制台（不能同时导入这两台 VM，这是因为控制台不允许具有相同 GUID 的节点）。但是，您还从 vCenter VC2 导入 VM。当自动发现运行时，它会首先连接到 VC1，按 GUID 检测 VM1，并且“虚拟机管理程序”列会更新为 VC1 的信息。稍后，当它连接到 VC2 时，它会按 GUID 检测 VM2，并且虚拟机管理程序列会更新为 VC2 的信息。

两台 VM 具有相同 GUID 的情况很少见。在最糟糕的情况下，如果发生这种情况，基于主机的无代理备份可能会备份错误的 VM，这是因为 Arcserve UDP 使用 GUID 来识别 VM。要解决该问题，您可以手动更改其中一台 VM 的 GUID。有关如何执行此操作的详细信息，请参阅《解决方案指南》中的相关主题。

无法登录 Arcserve UDP 控制台。即使在登录五分钟后，该控制台也会显示以下消息：

标识服务正在启动
要解决此问题，请打开 Windows 服务控制台，然后重新启动 Arcserve UDP 控制台服务、Arcserve UDP 管理服务。
					Arcserve UDP 用户管理控制台相关问题				
由于第三方组件中的某些错误，Arcserve UDP 用户管理控制台上某些对话框中的一些文本未本地化。
Arcserve UDP 用户管理控制台允许您使用特殊字符（如 [email protected]#$%^&*\ 及其他字符）创建角色名称。但是，您不能重命名、分配或删除此类角色。
					Arcserve UDP 恢复点视图相关问题				
在切换到 Arcserve UDP 恢复点视图后，挂接在备份会话中文件路径下的卷将无法被挂接。
如果卷仍被挂接，Arcserve UDP 恢复点视图会直接打开操作系统挂接的卷，而不是备份会话挂接的卷。
如果卷被卸载，在该文件路径下的 Arcserve UDP 恢复点视图中将不显示任何内容。
使用“挂接恢复点”挂接此种卷。				
					Arcserve UDP 代理 (Linux) 相关问题				
如果您在 Google Chrome 中打开 Arcserve UDP 代理 (Linux)，则作业状态选项卡中的行将不会与相应的列标题对齐。
不支持加密的卷。您不得备份加密的卷。
BMR 不支持 FakeRAID。如果您的备份节点是 RHEL 6.4 及更高版本、CentOS 6.4 及更高版本或 Oracle Linux Server 6.4 及更高版本且备份节点包括 Linux Software RAID，那么您必须使用基于 CentOS 的 Live CD 从此恢复点执行 BMR。
使用 RHEL 6.x 或 CentOS 6.x D2D 服务器从 RHEL 5.x 或 CentOS 5.x 恢复点中还原文件时，一些 SELinux （安全增强的 Linux）属性可能不会得到还原。
将两个安装软件包文件下载到本地文件夹时，此本地文件夹的完整路径不得包含任何特殊字符，除空格外，且路径仅应包括以下字符：a-z、A-Z、0-9、 - 和 _。
如果您使用本地作为备份目标，提交文件级还原作业或 BMR 作业，在此之后，如果要将备份目标修改为 NFS 共享或 CIFS 共享，则必须首先将 NFS 共享或 CIFS 共享添加到备份存储中。添加 NFS 共享或 CIFS 共享之后，打开“还原向导”并从“会话位置”下拉列表中选择“NFS 共享”或“CIFS 共享” ，然后重新提交该作业。
Oracle Linux 仅支持 Red Hat 兼容内核。您必须选择 Red Hat 兼容内核作为默认启动内核。Oracle Unbreakable 内核不被支持，并且它不应当是默认启动内核。
如果您使用 Live CD 在 Citrix XenServer 6.x 中启动 PVM，Arcserve UDP 代理 (Linux) 备份服务器将在 Live CD 中不可用。
					备份相关问题				
升级到 Windows 10 后，系统会删除卷的跟踪驱动程序高层筛选。BLI 驱动程序不能跟踪卷中的任何更改。因此，增量备份作业将转换为验证备份作业。
卷类的注册表 BLI 高层筛选将被删除。因此，BLI 驱动程序无法监视卷。
您可以在重新安装更改跟踪驱动程序后继续执行增量备份。
					请按下列步骤操作：				
通过从以下路径运行 UninstallDriver.bat 文件，卸载更改跟踪驱动程序。
<安装路径>\Arcserve\Unified Data Protection\Engine\BIN\DRIVER
通过从以下路径运行 InstallDriver.bat 文件，重新安装更改跟踪驱动程序：
<安装路径>\Arcserve\Unified Data Protection\Engine\BIN\DRIVER
操作基于 COM 的组件（如 VSS、VDS）时，备份、还原或 BMR 信息收集可能会失败。事件 ID 10006、1503 或 6287 可能会显示在 Windows 事件日志中。
日志事件中可以找到以下消息：“试图在标记为删除的注册表项上进行非法操作”或“Windows 检测到注册表文件仍在由其他应用程序或服务使用。此文件即将卸载。包含注册表文件的应用程序或服务之后可能无法正确运行。”
有关原因和解决方案，请参阅 Microsoft KB 文章 2287297。				
挂接卷失败，出现消息“无法将恢复点挂接到路径:“Z:”.功能错误。”				
将会话挂接到驱动器号失败。
当目标为 FAT32 卷上的本地文件夹时，将发生此问题。挂接驱动程序仅支持在 NTFS 卷上创建缓存文件。
添加新的注册表项，并将缓存文件自定义至其他卷上。
					请按照下列步骤操作：				
在 HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine 上创建注册表项“AFStorHBAMgmt”。
创建字符串值“CacheFilePath”。
					更多信息：				
挂接可写卷后，将通过挂接驱动程序创建缓存文件。为粒度还原编录/还原作业创建了可写卷。如果会话备份 Windows 8、Windows 2012 或更高版本操作系统上的卷，当您将会话挂接到驱动器号时，将始终挂接可写卷。
从 Arcserve UDP 代理 (Windows) UI 提交备份作业时，如果备份目标正在使用恢复点服务器上的数据存储，备份作业可能不会启动。
显示备份提交成功，但 Arcserve UDP 代理 (Windows) UI 中看不到任何作业监视器。这是因为备份作业达到数据存储中的最大并行节点计数设置。备份作业将置入等待队列。
打开 Arcserve UDP 控制台，挂起的作业监视器将显示在节点视图上。				
如果备份作业运行时重新启动 Arcserve UDP 代理 (Windows) 计算机，作业将在 Arcserve UDP 代理 (Windows) 主页上标记为“崩溃”，但是 Arcserve UDP 控制台上没有此作业的作业历史记录。这是因为作业结束时，作业历史记录项目将发送到 Arcserve UDP 控制台，但如果重新启动，则无法将作业历史记录从代理发送到服务器。				
作业监视器上基于主机的无代理验证备份作业的压缩百分比不正确。 
基于主机的无代理验证备份作业正在运行时，如果已在计划中启用压缩，则作业监视器上显示的压缩百分比将高于实际百分比。
所有其他备份作业无此问题，包括代理备份作业和基于主机的无代理完全/增量备份作业。
活动日志中输出的压缩百分比是正确的。在基于主机的无代理验证备份作业完成后引用此百分比。				
					BMR 相关问题				
创建启动工具包失败，出现以下错误：
“无法将语言包集成到 BMR ISO 映像”。
此问题由第三方防病毒软件（McAfee）筛选驱动程序引起，但在使用其他第三方筛选进也会发生。
禁用您的防病毒软件并重新尝试启动工具包创建。				
无法在执行 BMR 之后启动服务器。
源计算机是向配有不同硬件的物理计算机或 Hyper-V 服务器上的虚拟机执行 BMR 的 Active Directory 服务器时，该服务器不启动，并显示蓝屏，出现以下消息：
停止：c00002e2 因为以下错误，目录服务无法启动：连到系统上的设备没有发挥作用。错误状态：0xc0000001。
将系统重新启动到 BMR PE 环境，重命名 C:\Windows\NTDS 文件夹中的所有 *.log 文件，然后重新启动系统。例如，将文件 edb.log 重命名为 edb.log.old，然后重新启动系统。				
无法在 BMR 期间将源磁盘映射到目标磁盘，即使两个磁盘的大小恰恰相同。
目标计算机是 2008 Hyper-V 服务器或 2008R2 Hyper-V 服务器上具有 IDE 磁盘的 VM 时，您在 BMR 期间可能无法映射磁盘/卷。
如果您使用 BMR 将数据还原到 2008 Hyper-V 服务器或 2008R2 Hyper-V 服务器上具有 IDE 磁盘的 VM，则无法将源磁盘/卷映射到目标磁盘/卷，即使两个磁盘的大小相同也是如此。这是因为您在 2008 Hyper-V 服务器或 2008R2 Hyper-V 服务器上创建 IDE 磁盘时，实际磁盘大小小于您指定的大小。
在 VM 上创建更大的磁盘。例如，如果您想从 25 GB 的磁盘还原数据，建议在目标 VM 上创建 26 GB 的磁盘。				
如果使用 Windows ADK 8.1 创建 BMR ISO，则在使用此 ISO 启动计算机之后，您可能发现 PE 系统中没有检测到磁盘。
此问题出现在 VMware ESX Server 上。对于 Windows 2003 VM，默认的磁盘控制器为 LSI Logic SCSI 适配器，且 Windows ADK 8.1 不包含这种 SCSI 适配器的驱动程序。在某些带有旧版 SCSI 适配器的旧版服务器上也可能出现此问题。
要解决此问题，请从硬件供应商网站获得驱动程序，并从 BMR 用户界面加载相应驱动程序。				
					硬件快照相关问题				
如果 VMware VM 备份作业使用硬件快照，将在调试日志中显示多条以下消息。多条消息会增加安装 Arcserve UDP 的卷的磁盘空间占用。我们正与 NetApp 合作解决此问题。
[VDDKLOG] SSLCheckLockingCallback: locking callback overwritten!Expected 7FEE3A836E0, saw 113C2420
作为变通方法，请将以下路径中的 VDDKLogLevel 注册表项设为 0：
\HKEY_LOCAL_MACHINE\Software\Arcserve\Unified Data Protection\Engine\
CSV 可传输快照有时可能失败，并恢复为软件快照。在硬件提供方多次重新尝试创建可传输快照后，会发生这种情况。您可以在 Windows 事件查看器中找到以下错误。我们正与 NetApp 合作解决此问题。
在以“10”秒的时间间隔重试“100”次后，无法跨存储系统“xxx”的多个卷创建快照副本“{xxx}_backup”。
对于 cDOT 的当前 Data ONTAP 版本，硬件快照使用 FlexClone（即使它未获得许可）。这是一个已知的 NetApp 问题。要继续备份而不使用 FlexClone 许可，请在 Arcserve UDP 代理服务器上创建注册表项。
					按照以下步骤创建注册表项：				
登录到代理服务器。
在以下位置创建 DoNotUseFlexCloneLicenseToCloneLun 项：
HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine
创建以下字符串值，并将值设置为 1。
DoNotUseFlexCloneLicenseToCloneLun
如果启用更改块跟踪并在 ESXi 6.0 或 ESXi 6.0 上运行，则在备份 VMware VM 时会检测到潜在问题。
VMware 最近发布了一篇 KB 文章，其中表明在 ESXi 6.0 或 ESXi 6.0.x 中，在更改块跟踪 (CBT) 中引入了一个缺陷，它会导致 CBT 返回错误的更改扇区列表。Arcserve UDP 可能会受到此问题的影响，从而导致不一致的虚拟机备份（完全和增量备份）。有关详细信息，请参阅 VMware KB。
如果出现该问题，编录作业可能会失败，并且检查恢复点可能会报告错误。 
VMware 已发布针对该问题的修补程序。在您的 ESXi 主机上应用该修补程序。有关详细信息，请参阅 VMware KB 文章或 Arcserve KB 文章。
Hyper-V 中的 SUSE Linux Enterprise Server 12 VM 无代理备份将失败，并且 VM 客户操作系统会在备份后挂起。
如果 Hyper-V 主机是 Windows 2012 R2，VM 的客户操作系统是带有运行级别 5（使用图形界面）的 SUSE Linux Enterprise Server (SLES) 12，则会出现此问题。在这种情况下，无代理备份作业会在“拍取快照”阶段挂起并最终失败。之后，VM 客户操作系统会无法响应。
这并不是 Arcserve UDP 的问题，而是 Windows 和 SUSE 的兼容性问题。在 Hyper-V 主机中使用 diskshadow 命令创建 VSS 快照时，也会出现同一问题。按如下步骤确认此问题：
登录 Hyper-V 服务器。
以管理员身份打开 Windows 命令行。
在命令行中，键入以下命令。
键入“diskshadow”并按 Enter 键。
键入“add volume X:”并按 Enter 键。（X: 是 VM 的虚拟磁盘文件和配置文件所在的卷。如果 VM 的磁盘文件或配置文件在不同的卷上，请重复此命令，以添加所有卷。）
键入“create”并按 Enter 键。
快照创建完成（这可能要花费一些时间）后，键入“end backup”，然后按 Enter 键。
键入“exit”，然后按 Enter 键。
检查 VM 客户操作系统是否会挂起。
依次查看“Windows 事件日志”、“应用程序和服务日志”、“Microsoft”、“Hyper-V VMMS”、“管理”。应该有一个错误日志表明在创建快照期间 VM 失败。
到目前为止还没有解决方法。我们建议您使用 Microsoft 解决根本原因。或者，您可以尝试将 SLES 12 的运行级别从 5 更改为 3（不使用图形界面），但这并不能保证能解决任何问题。
操作前检查 (PFC) 会针对 VMware VM 报告“无法访问虚拟机”
对于 VMware VM，操作前检查 (PFC) 会针对数据一致性检查报告以下警告消息，即使您已经提供了相应的凭据也是如此。
未验证，因为应用程序无法访问虚拟机。确认用户登录凭据正确且拥有管理权限。 
仅针对 VMware VM 的 PFC 存在此问题。其他功能（如备份）不受影响。变通方法是在安装 Arcserve UDP 控制台的计算机上安装 Arcserve UDP 代理（无需启动代理服务）。
对驻留在 ESXi 5.5 或更早版本上的 VM，使用 SAN 传输故障切换到非 SAN 传输模式以进行备份和还原
即使可以使用 SAN 传输模式，无代理备份或还原作业仍然使用 HotAdd、NBD 或 NBDSSL 传输模式。
这是 VMware VDDK 6.0.1 的已知问题。目前还没有来自 VMware 的解决方案。有关详细信息，请参阅“VDDK 6.0.1 中的已知问题”版本说明。
当 VM 虚拟磁盘的已配给大小是 4 TB 或 4 TB 的倍数时，使用 SAN 传输故障切换到非 SAN 传输模式，以进行备份和还原
即使可以使用 SAN 传输模式，当 VM 虚拟磁盘的已配给大小是 4 TB 或 4 TB 的倍数时，备份和还原作业仍然使用 HotAdd、NBD 或 NBDSSL 传输模式。
这是 VMware 已知问题，据 VMware 透露，此问题已通过以下修补程序得到解决：
•	对于 ESXi 5.5 - 修补程序版本 ESXi550-201504001 (2112672)
•	对于 ESXi 6.0 - 修补程序版本 ESXi600-201505001 (2116125)
变通方法是避免使用 4 TB 的倍数作为已配给大小。例如，不要使用 4 TB 或 8 TB；而要使用 3.9 TB 或 8.1 TB。
使用 VMware Tools 快照静止方法时，VMware 系统的无代理备份会备份损坏的快照。
在您使用 VMware Tools 停止 VMware VM 时，该快照包含损坏的数据。备份从快照读取数据，因此备份的数据也发生损坏。有关此问题的更多信息，请参阅 VMware KB 文章。
					注意：					 所有 VMware ESXi 版本以及具有客户操作系统 Windows 2008 R2 SP1 和 Windows 2012 的虚拟机上都会出现此问题。因为 VMware 在这种情况下不返回错误，所以 Arcserve UDP 无法检测到数据损坏问题。您在尝试还原数据之前可能不会意识到此问题。
执行以下任务可检测和解决该问题：
					恢复点检查  - 从恢复点挂接卷并通过在备份作业结束时运行 Microsoft 工具 CHKDSK 来验证数据一致性。有关 chkdsk 工具的更多信息，请参阅《Arcserve UDP 解决方案指南》。chkdsk 工具可能需要较长时间运行。作为最佳实践，请为每周或每月备份作业启用此选项。
					在 VM 的客户操作系统中禁用有问题的编写器 - 					如果“恢复点检查”检测到问题，请执行 Arcserve 					KB 文章中的“如何检查此缺陷是否可能会影响您”中所述的步骤。 VMware 推荐的变通方法是在 VM 的客户操作系统中禁用 VSS 编写器“MSSearch 服务编写器”（如果未安装，则忽略它）和“卷影副本优化编写器”（通常位于每个 Windows VM 中）。您可以按照 VMware KB 文章手动执行此操作。Arcserve UDP 还提供了一种简单的方式，可在备份期间禁用有问题的编写器。有关此已知问题的详细信息，请参阅《解决方案指南》“故障排查”一章中的“基于主机的无代理备份的文件系统编录作业失败或恢复点检查失败”主题。
VMware VM 中的“虚拟机内的 Microsoft VSS”快照静止方法可能会导致不一致的备份
使用“虚拟机内的 Microsoft VSS”快照静止方法备份 VMware VM 时，备份可能会不一致。特别是在备份安装有应用程序（如 Exchange）的 VM 时。
变通方法是在此问题得到解决之前使用 VMware Tools 快照静止方法，以及在 VM 的客户操作系统中禁用 VSS 编写器 MSSearch 服务编写器和卷影副本优化编写器。
将群集 VM 恢复到原始 Hyper-V 群集之后，网络适配器无法连接到虚拟交换机，并在活动日志中显示警告消息：
无法将网络适配器 <<适配器名称>> 连接到虚拟交换机。
备份 VM 时，群集 VM 会在拍取快照之前发生故障切换。该故障切换会导致备份会话中记录的 Hyper-V 主机与 VM 配置不一致。
您可以将网络适配器手动连接到 Hyper-V 主机上的虚拟交换机，或使用“ 还原到备用位置 ”选项恢复 VM，该选项让您可以设置该 VM 的还原配置。
在 Hyper-V 2012 或更高版本中，尽管虚拟机的基于主机无代理备份作业已完成，但此虚拟机仍会停留在“正在备份”状态。
尽管一台虚拟机的备份作业已完成，但这台虚拟机在 Hyper-V 管理器中的状态仍为“正在备份”。因此，如果此 VM 的另一个备份作业在这时启动，它将失败并出现错误“Hyper-V VSS 编写器在处理该虚拟机时遇到错误”。此外，您无法执行某些操作，例如此时在 Hyper-V 管理器中打开/关闭 VM。如果该 VM 是 Hyper-V 群集，您将无法对其执行实时迁移。
在以下情况下会发生此问题：
同时或在相近时间（在 1 分钟之内）开始多个备份作业。
一个或多个备份作业已完成，但仍有至少一个备份作业仍在进行中。
尽管 VM 被“锁定”，您仍可以照常使用客户操作系统。因此，这对客户操作系统的使用/可用性没有影响。但是，如果您有顾虑且想要避免这种情况，则可以执行以下任一操作：
使用基于主机的无代理备份的“ 资源 ”选项卡上的“ Hyper-V 快照分离 ”选项。有关更多信息，请参阅《Arcserve UDP 解决方案指南》。
使用不同计划来保护不同大小的虚拟机。换言之，将具有类似大小的 VM 包括在一个计划中，以使这些备份作业花费基本相同的时间，同时为这些计划设置不同的排定。
执行 VMware 虚拟机的增量备份作业时，增量备份作业的备份数据大小可能会大于预期。
这是 VMware 已知问题，涉及更改块跟踪 (CBT)。在应用程序级静止的情况下，更改块跟踪会高估更改。
在 VMware ESXi 5.5 或更高版本以及 VMware ESX 5.1 修补程序 02 中修复该问题。如果 VMware vCenter Server 5.5 管理任何 VMware ESXi 5.1 主机，都应该对其应用该修补程序。有关此修复的详细信息，请参阅 VMware KB。
如果您仍遇到此问题，请在代理服务器上设置以下注册表： 
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\<VM 实例 UUID>]
"ResetCBT"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\502d3c43-e3c9-9919-78f9-89082ca5e1cc]
"ResetCBT"=dword:00000001
					注意：设置了注册表值后，下一个增量备份作业转换成验证备份，然后随后的增量备份作业继续以适当的大小运行。				
由于 VMware 的已知问题，启用存储 DRS 后，进行备份作业时将发生存储 vMotion；备份作业可能失败。该活动日志指定以下消息：“无法打开 VMDK 文件。”VMware 报告以下错误：“未找到文件。”
有关详细信息，请参阅 VMware KB 文章 2055943。
VMDK 大于 2 TB 的 VM 的恢复失败，因为 VM 无法创建快照。
备份源 VM 的 VMDK 大于 2TB，版本低于 5.5 的 ESX/ESX (i) 服务器仅支持最大 2TB 的虚拟磁盘。不过，在 VM 转换期间，会发生以下错误：
在 vSphere Client 中：
“创建的虚拟机快照 VIRTUALMACHINE 文件 <未指定的文件名> 大于数据存储‘<未指定的数据存储>’支持的最大大小”。
“文件大于数据存储支持的最大大小”。
在 ESX/ESXi 4.x 的 hostd 日志文件中：
“快照来宾无效：文件对于文件系统过大。”
在 ESXi 5.0/5.1 的 hostd 日志文件中：
“无法执行快照操作:错误：(21) 文件对于数据存储过大。”
这是 VMware 限制。版本低于 5.5 的 VMware ESX/ESX (i) 服务器支持的最大大小是 2T-16 GB，相当于 2032 GB。
建议将 VMware ESX(i) Server 5.5 用作目标，以便对大磁盘执行转换。
有关详细信息，请参阅 VMware KB 文章 1012384。				
ESXi 服务器上运行的 Windows VM 的单个 SCSI 控制器上连接超过 7 个磁盘时，创建快照将失败。
在包含 SCSI 控制器（连接超过 7 个 VMDK）的虚拟机上运行备份作业时，备份作业将失败。备份作业失败的原因是 VMware 要求特定 SCSI 控制器上的 VMDK 具有最大数目的可用插槽，才能创建快照。SCSI 控制器最多可有 15 个插槽。例如，如果 SCSI 控制器有 7 个 VMDK，可为每个 VMDK 创建一个快照。（总计 14 个已用插槽和 1 个可用插槽。）如果 SCSI 控制器有 8 个 VMDK，备份作业将失败，因为只有 15 个可用插槽，无法创建快照。
					注意：另外，手动创建快照也会失败。
对于单个 SCSI 控制器上具有超过 7 个磁盘的虚拟机，请执行下列步骤：
关闭虚拟机。
创建多个瘦虚拟磁盘，添加更多 SCSI 控制器。
在多个 SCSI 控制器之间分发现有磁盘。
打开虚拟机。
现在可为每个 VMDK 创建快照。
这是一个 VMware 限制问题，Arcserve Backup 仅支持用于备份的 VMDK 磁盘数目。
有关详细信息，请参阅以下 VMware 知识库文章：http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2015181									
使用 HTTP 协议和端口 80 时，如果从 vCenter Server/ESXi 5.0 Update 3 及更高版本导入 VMware 虚拟机，连接将失败。
这是一个已知的 VMware 问题。以下链接将打开 VMware KB 文章：http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2069149									
从 Hyper-V 服务器导入 VM 时，基于主机的无代理 Hyper-V VM 还原作业覆盖 VM 后，VM 将被禁用。禁用 VM 的原因是，已还原 VM 的实例 GUID 与从 Hyper-V 服务器导入的原始实例 GUID 不同。VM 实例 GUID 无法恢复为原始实例 GUID。
要解决此问题，请从 Central Protection Manager 中删除旧的 VM，然后导入新的 VM。				




    

Arcserve UDP 作业运行时，会出现 ESX/ESXi/vSphere 5.5 紫屏死机。
这是一个已知的 VMware 问题，影响 ESXi 5.0、5.1 和 5.5 主机以及使用 E1000 和 E1000e 虚拟网络适配器的虚拟机。
					注意：会在以下 VMware 更新中解决此问题。
ESXi 5.0 修补程序版本 ESXi500-201401001。有关详细信息，请参阅 VMware KB。
ESXi 5.1 Update 2，在 VMware 下载中提供。有关详细信息，请参阅 VMware KB。
ESXi 5.5 Update 1，在 VMware 下载中提供。有关详细信息，请参阅《VMware ESXi 5.5 Update 1 版本说明》。
ESXi 6.0 GA，在 VMware 下载中提供。有关详细信息，请参阅《VMware ESXi 6.0 版本说明》。
切换到 VMXNET3 适配器。有关详细信息，请参阅 VMware KB 文章 2059053。
在备份期间，Arcserve UDP 代理将子磁盘数据合并到相应的父磁盘并创建一个磁盘映像。因此，VM 备份后不再存在父子磁盘关系。因此，只恢复父磁盘，“差分磁盘”配置丢失，但不会丢失数据。在虚拟机恢复后,可以检索单个合并磁盘中的数据.
此现象对于无代理备份而言是正常的。成功恢复 VM 后，可以手动配置“差分磁盘”。				
存在重复的 VM 实例 UUID 时，导入 VM 将失败。				
将 VM 导入到节点视图时，如果已将具有相同 VM 实例 UUID 的其他 VM 添加到节点视图，则该操作将失败。
Host-Based VM Backup 计划已保存，如果所选代理计算机安装有 Arcserve D2D r16.5，该计划将失败。				
如果 Host-Based VM Backup 计划包括的代理计算机安装有早期版本的 Arcserve D2D（例如，r16.5），保存该计划时将显示错误消息“找不到分派方法”。
发生该问题的主要原因是当前版本的 API 与早期版本 Arcserve D2D 的 API 不兼容。要解决此问题，您可以手动将 Arcserve D2D 升级为当前版本的 Arcserve UDP 代理 (Windows)。
Host-Based VM Backup 作业可能在 VM 的“开始备份”阶段挂起。				
Host-Based VM Backup 作业处于挂起状态几个小时，且无法继续。
根据活动日志的进程 ID 结束 afbackend.exe，删除 VM 快照（如果有），并重新提交备份作业。
在执行 Host-Based VM Backup Hyper-V 虚拟机 (VM) 的还原作业后，磁盘的状态（除已恢复虚拟上的启动盘外）均为“脱机”。				
在默认情况下，操作系统的行为创建脱机状态。
Windows Server 2008 中引入了 SAN 策略，以保护多个服务器访问的共享磁盘。来自源 VM 的默认 SAN 策略对于除启动盘以外的所有 SAN 磁盘为“脱机共享”。“将策略设置为脱机”启用 SAN 磁盘在启动期间脱机。恢复后，已创建 VM 的新磁盘。VM 中的磁盘文件显示为操作系统将其视为脱机的 SAN 磁盘。将脱机磁盘设置为恢复联机后，即使重新启动系统，磁盘仍将保持联机状态。
作为变通，请在备份前为源虚拟机指定 DISKPART.exe 命令：SAN POLICY=OnlineAll 设置。因为磁盘可在其他服务器中共享，所以数据损坏会发生。您必须使用正确的 SAN 策略才能保护数据。
					DISKPART.EXE 命令行				
					查询 SAN 策略：				
DISKPART > san
SAN 策略：脱机共享
					更改 SAN 策略：				
DISKPART > san policy=OnlineAll
DISKPART 成功为当前的操作系统更改 SAN 策略。
将不备份连接在 Hyper-V 虚拟机上的 iSCSI 硬盘。
备份 Hyper-V VM 后，还原 UI 不会列出 iSCSI 设备上的卷。
在 Arcserve UDP 中创建基于代理的备份计划，或使用 <cadp_agt_windows> 备份虚拟机。				
客户操作系统是 Windows Server 2003 时，Hyper-V VM 上基于主机的无代理备份作业无法执行先行/后继命令。
对于 Hyper-V VM 上基于主机的无代理备份作业，如果客户操作系统是 Windows Server 2003，将无法执行先行/后继命令。活动日志输出警告“虚拟机名称不是预期名称。无法执行先行/后继命令”。
Windows Server 2008、Windows Vista 或更高版本的操作系统没有此问题，应当使用这些版本的操作系统。				
					安装/远程部署相关问题（代理）				
安装挂接驱动程序失败，在调试日志中错误代码 1460。
Windows 安装程序 API 报告错误 1460，即意味着超时时段到期。默认超时值是 300 秒，用于更新设备驱动程序。
要调整超时值，请执行以下步骤：
在“开始搜索”框中键入 gpedit.msc 并按下 Enter 键。
出现 UAC 提示时，单击继续。
导航到以下策略位置：
Computer Configuration\Administrative Templates\System\Device Installation
启用以下策略设置：
配置设备安装超时。
指定新的超时值，以秒为单位。				
即时 VM 的名称和位置与预期结果不同。
当您使用 ESX 信息登录并选择资源池作为即时 VM 的位置时，即时 VM 位于 ESX 主机下方，并且不在此资源池中。如果您从控制台删除此即时 VM，并使用同一名称重新创建一个即时 VM，则它将在此即时 VM 的名称（而不是时间戳）中添加后缀 (1)，这不符合预期。
这是因为 ESX 服务器由 vCenter 管理。使用 vCenter 登录信息创建即时 VM。
如果您创建无代理备份计划，并指定本地路径作为备份目标，则不能从此类恢复点创建即时 VM。要解决此问题，请使用共享文件夹作为备份目标。
如果您使用 IP 地址添加节点，接着创建备份计划，并指定共享文件夹作为备份目标，则可能不会从节点列表视图中创建即时 VM。不过，您可以从目标视图中创建即时 VM。或者，您也可以使用主机名更新节点，并尝试再次创建即时 VM。
如果恢复点具有已镜像的系统卷，而您使用该恢复点创建即时虚拟机（即时 VM），则可能会遇到一些错误，如黑屏死机。
重新启动恢复服务器后，无法在 Hyper-V 中启动即时 VM
当我启动即时 VM，然后重新启动 Hyper-V 恢复服务器时，即时 VM 可能无法启动。
要解决此启动故障，请重新启动即时 VM。
在 Windows Server 2012 中，在动态磁盘上创建 NFS 可能会失败。要避免此问题，请使用基本磁盘。您还可以应用修补程序来解决此问题。有关该修补程序的详细信息，请参阅 Microsoft 中的 KB 文章。				
当对用作恢复服务器上的 VMware NFS 的 Windows 卷进行格式化时，即时 VM 创建会失败。
我已指定 Windows 卷作为 NFS 共享文件夹，并将该共享卷的路径提供为即时 VM 文件路径。当我格式化 Windows 卷，然后尝试创建即时 VM 时，将无法创建即时 VM。无法创建即时 VM 的原因是 ESXi 主机无法添加 NFS 数据存储。VMware 显示以下错误消息：
VMware 创建 VM 失败。
vmkernal.log 文件中显示以下错误日志：
No underlying device for major, minor
要解决该问题，请在恢复服务器上执行以下步骤：
依次打开“控制面板”、“系统和安全”、“管理工具”。
此时打开“管理工具”对话框。
双击“服务”。
此时将显示“服务”对话框。
右键单击“NFS 服务器”，然后单击“停止服务”。
右键单击“NFS 服务器”，然后单击“启动服务”。
再次使用该卷创建即时 VM。
该即时 VM 得以创建。
					日志视图相关问题				
节点名称为“VM（主机名称）”且通过单击查看日志链接加载日志视图时，日志筛选不起作用。
在日志视图中，如果受保护的 VM 没有主机名，则其节点名称值显示为“VM（节点名称）”。在这种情况下，其他筛选不起作用。
您可以将节点名称从“VM （主机名称）”手工修改为“主机名称”，然后所有筛选都将正常运作。例如，将节点名称 “VM (xxxxx01-AB)”改为“xxxxx01-AB”。				
					Microsoft Exchange 相关问题				
Exchange 数据库还原失败，错误如下：“无法安装"。
Exchange 服务器已安装在 VM 中，且运行 Arcserve UDP 代理 (Windows) 保护此 VM 时会发生该问题。备份运行一段时间后，如果 VM 恢复为先前保存的 VM 快照，而您尝试将 Exchange 数据库恢复到原始位置时，还原将失败，并显示错误“Exchange 存储组/数据库 [数据库名称] 已还原到其原始位置，但无法挂接”。
根本原因仍在调查中，但是目前似乎与 Exchange 数据库和最新事务日志文件内记录的时间戳有关。
尝试将 Exchange 数据库恢复到备用目录，或在执行还原之前卸载数据库并删除目标文件夹中的所有文件。				
					Microsoft SQL Server 相关问题				
如果 Microsoft SQL Server 无法分配更多内存，Arcserve UDP 控制台可能响应较慢。
Microsoft SQL Server 可能需要分配更多的内存来处理查询，尤其是当 Arcserve UDP 数据库中存在过多数据时。但是，如果由于内存不可用或配置的最大限制导致 Microsoft SQL Server 无法获取内存，那么查询处理将变得非常慢，进而影响 Arcserve UDP 控制台的响应速度。
使用日志/删除删除数据库中的一些日志，然后重新启动 SQL 服务。				
					恢复点服务器 (RPS)/数据存储相关问题				
手动合并作业不会执行，并显示错误
手动提交合并作业时，该作业不会运行，并且在活动日志中显示以下消息：
无法运行 <节点名称> 的合并作业，另一作业正在运行
出现该错误的原因可能是，存在该节点的其他作业正在同一恢复点服务器但不同数据存储中运行。作为变通方法，请等待这些作业完成，然后重试。
防病毒软件意外删除数据存储文件。
备份或复制作业失败，错误为“系统找不到指定的文件”。
检查 Windows 事件日志。McAfee 将数据存储文件（例如 P0000000042.data）检测为 Exploit-ScriptNull 木马病毒并将其删除。
配置防病毒设置，在排除列表中设置恢复点服务器 (RPS) 数据存储的位置。
					注意：某些防病毒软件要求您在服务器端设置排除列表。				
目标为重复数据消除的数据存储时，取消复制作业可能需要几分钟时间。
将网络限制设置为很低的带宽或目标 RPS 服务器的网络吞吐量较慢时，会发生这种情况。因此，可能需要等待几分钟时间，才能发送排队的数据。
等待复制作业正常退出。				
如果存在以下两种状况，修改数据存储时，数据存储的哈希内存显示不正确。
RPS 服务器的内存小于等于 4 GB。
创建数据内存时，未选择哈希内存的最大值。				
					恢复点服务器 (RPS)/从 Hyper-V/相关节点导入				
尝试按 IP 地址或节点名称添加节点时，可能发生“需要管理员权限”错误并阻止您添加节点。尝试从 Hyper-V 导入时，“请检查帐户是否对 Hyper-V 服务器有管理员权限”错误会发生，并阻止您导入虚拟机。
尝试在支持用户帐户控制 (UAC) 的 Windows 操作系统（Windows Vista 或更高版本）上按 IP 地址或节点名称添加节点或尝试从支持 UAC 的 Hyper-V 服务器导入虚拟机时，如果使用的新 Windows 用户帐户是在管理员组中的本地帐户，而不是内置管理员，则会显示以下消息：
“需要管理员权限。”
使用内置管理员或域管理员。或者，您可以禁用远程 UAC。
这是称为“UAC 远程限制”的默认 Windows 行为。如果您仍想使用此帐户来添加节点，请执行以下步骤禁用远程 UAC：
单击“开始”，在“搜索程序和文件”字段中键入 regedit，然后按 Enter 键。
此时将打开 Windows 注册表编辑器。
					注意：您可能需要提供管理凭据，才能打开 Windows 注册表编辑器。
查找并单击以下注册表项：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
从“编辑”菜单，单击新建，然后单击 DWORD (32 位) 值。
指定 LocalAccountTokenFilterPolicy 作为新条目的名称，然后按 Enter 键。
右键单击 LocalAccountTokenFilterPolicy，然后单击“修改”。
在“值”数据字段中指定 1，然后单击“确定”。
退出注册表编辑器。
有关 Windows 行为的详细信息，请参阅文章 http：//support.microsoft.com/kb/951016。				
无法为节点删除指定的管理程序。
此版本未提供为节点删除管理程序的功能。
删除节点然后重新添加。				
尝试将已由某个控制台管理的节点添加到其他控制台时，不显示警告或弹出消息。
利用 Arcserve UDP 的一体化 UI，用户不会有多个 Arcserve UDP 控制台，因此仅在旧服务器无法使用时，才会出现将代理从一个服务器移至另一服务器的情况。
将节点从一个控制台移至另一控制台的情况很少出现。				
					注册表相关问题				
如果备份目标是 Windows Server 2012 上启用重复数据消除的 NTFS 卷，且 Arcserve UDP 代理 (Windows) 安装在 Windows 2003 上，还原、合并或编录作业可能失败。该作业失败，出现 Windows 错误代码 50 和消息“不支持该请求”。
将 McAfee 或其他第三方软件安装在 Windows Server 2012 上时，它们会在注册表中设置 EnableECP=1。
在注册表中，在以下注册表项下将 EnableECP 的值从 1 更改为 0：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanManServer\Parameters
有关详细信息，请参阅 http://support.microsoft.com/kb/2817216。				
					复制相关问题				
在复制源端中止 RPSReplication.exe 进程可能导致第二个复制作业失败。
第二个复制作业将以准备状态挂起，并于 10 分钟后失败。
您不需要执行任何特定操作。第二个复制作业失败后，将触发补充作业。				
					Arcserve UDP Exchange Granular Restore (AEGR) 实用工具相关问题				
当使用 Arcserve UDP Exchange Granular Restore 实用工具时，所有项目均不会还原到活动服务器。
还原作业之后，以下项目属性可能无法正确还原：
InternetHeaders
RTFCompressed
Codepage
DateCompleted
TaskRecurrence
RecurrencePattern
AppointmentTimeZoneDefinitionEndDisplay
ReminderTime
CommonEnd
AppointmentStartWhole
AppointmentEndWhole
BusyStatus
Meeting Owner
任务的公司名称
使用“导出到 PST”选项来还原丢失的项目。
					还原相关问题				
使用 Update 4 或更低版本的代理时出错。 
使用 Update 4 或更低版本的代理时，会出现以下错误：
将 Exchange DB 还原到原始位置失败。此时将显示以下错误消息：
“Exchange 存储组/数据库已还原到其原始位置，但无法挂接它”。
当使用重放日志转储 Microsoft Exchange 数据库时，在作业完成后，日志不会重放。
将这些代理升级到 Arcserve UDP 代理版本 6.0。
将文件还原到其他位置（远程共享文件夹）失败，活动日志中的错误消息为“访问被拒绝”。
还原目标为远程共享文件夹（如 \\FileServer\ShareFolder\RestDest），并且备份目标为具有相同路径的远程共享文件夹（如 \\FileServer\ShareFolder\RestDest）时，将发生错误。
如果用于连接到根共享文件夹的用户帐户不在权限列表中，无论用于还原目标文件夹的帐户为何，还原作业都将失败。
添加为备份目标分配的用户帐户，以构建到根共享文件夹权限列表的连接，并确保用户帐户具有还原文件的适当权限。
将用户帐户添加到备份操作员组，并确保其具有覆盖安全限制的权限。				
升级操作系统后，从 Arcserve UDP 代理 (Windows) 恢复文件时，您可能需要重新输入加密密码或会话密码。
如果恢复点启用了加密，则无需输入从当前服务器备份的恢复点的密码。但是，如果升级 Windows 操作系统（例如，从 Windows 2008 升级到 Windows 2008 R2），Arcserve UDP 代理 (Windows) 用户界面的密码不会自动填充，您必须重新输入密码。
记录恢复点加密密码或会话密码，并保存在安全位置以备检索之需。				
无法在还原过程中打开 VMDK 文件。
在还原 VMware 虚拟计算机时，我遇到以下错误：
您没有该文件的访问权限，有关详细信息，请参阅还原调试日志。如有必要，请联系 Arcserve 支持。
您可以查看还原调试日志中的以下日志条目：
[VDDKLOG] CnxAuthdConnect:Returning false because SSL verification requested and target authd does not support SSL
[VDDKLOG] CnxConnectAuthd:Returning false because CnxAuthdConnect failed
[VDDKLOG] Cnx_Connect:Returning false because CnxConnectAuthd failed
[VDDKLOG] Cnx_Connect:Error message:SSL required
该错误的原因是在 VMware ESX 主机上禁用了 SSL 身份验证。要解决此错误，请执行以下方法之一：
					使用 vSphere Client				
登录到 VMware vCenter/ESX  服务器。
依次单击“配置”、“高级设置”、“配置”、“默认安全性”。 
打开 ESX 服务器设置。
启用以下选项：
config.defaults.security.host.ruissl
如果数据存储上有备份会话，则当您单击“恢复 Virtual Standby”时，虚拟备机作业不会启动。
系统会将相应节点备份到 RPS 数据存储，将其复制到另一个 RPS 数据存储，然后使用复制源创建虚拟备用计算机。计划部署之后，如果虚拟备机作业存在较早的会话，那么您可以直接恢复 Virtual Standby。但在您提交作业之后，虚拟备机作业将不会启动。
要解决该问题，请首先执行手动复制。右键单击该节点，然后单击“立即复制”。复制完成后，即可恢复虚拟备机作业。
当转换器正在使用 Arcserve UDP 5.0 版且监视器（代理）正在使用 Arcserve UDP 6.0 版时，无法运行虚拟备机作业。
虚拟备机作业失败，并出现以下错误：
无法获取磁盘签名 (签名为空)
在 Arcserve UDP 6.0 版中，VMWare VDDK lib 从版本 5.5 升级到版本 6.0。在 VDDK v6 中，初始化 VDDK lib 需要一个名为指纹的新字段。从 VSB 转换器进行的调用基于 Arcserve UDP 版本 5.0（其中缺少指纹）。这会导致从转换器到监视器的调用失败
要解决此问题，请将转换器更新到 Arcserve UDP 6.0 版。
将源节点上的 Arcserve UDP RPS 或 Arcserve UDP 代理升级到 Arcserve UDP 6.0 后，Hyper-V 上的虚拟备机作业失败。但是，Hyper-V 服务器上的 Arcserve UDP 代理不会升级。
Arcserve UDP 代理 (Windows) 将备份到 Arcserve UDP RPS 数据存储，并且 RPS 将升级到 Arcserve UDP 6.0。此外，Arcserve UDP 代理 (Windows) 将备份到共享文件夹，并且代理将升级到 Arcserve UDP 6.0。Hyper-V 上的虚拟备机 VSB 作业失败，并显示以下错误：
找不到 {http://webservice.arcflash.com}IsVmFileExist 的分派方法。
找不到 {https://webservice.arcflash.com}IsVmFileExist 的分派方法。
将 Hyper-V 服务器上的 Arcserve UDP 代理升级到 Arcserve UDP 6.0。
开机时，磁盘以脱机状态启动。发生这种状况是因为，在 Windows 2008 或更高版本的操作系统中引入了 SAN 策略。操作系统保护多个服务器访问的共享磁盘。服务器首次检测到磁盘时，Windows 将磁盘置于脱机状态。磁盘置于联机状态后，磁盘将仍保持联机状态。
此行为的其他原因与打开包含“只读”卷的虚拟机有关。要改变这种情况，请将卷置于可写状态的磁盘之上。
应用程序不支持使用 VMware 链接模式导入 vCenter 服务器。要保护链接模式组中的所有 vCenter 服务器实例，请分别添加每个 vCenter 服务器实例。
源计算机的系统卷或启动卷位于动态磁盘上时，Virtual Standby 不支持将恢复点转换为 Hyper-V 格式。
Virtual Standby 不支持创建 Virtual Standby 任务，该任务可用于定义在 Windows 2008 R2 SP1 和 windows 2012 Hyper-V Server 系统上保护的虚拟机所用的动态 RAM 数量。
在使用当前快照执行 V2P 恢复时，可能会显示一条指示以下内容的消息：
无法获取恢复点信息。
使用最新的快照执行 V2P 恢复，且在将 Virtual Standby 任务重新部署到节点之后节点的转换作业未完成时，会出现此行为。
提交 Arcserve UDP 代理备份作业来捕获节点的当前状态。然后执行节点的裸机恢复。
关闭 Virtual Standby 虚拟机，然后提交 Virtual Standby 转换作业来为节点创建当前恢复点快照。
V2P 用户界面可能不显示最新的快照。从最新的快照完成 V2P 恢复之后执行 V2P 恢复时，会出现此行为。
请使用 Arcserve UDP 代理裸机恢复执行 V2P 恢复。
备份源计算机（已安装 Arcserve UDP 代理时）包含原生 4KB 扇区磁盘，且 Arcserve UDP 代理备份作业已备份 4KB 扇区磁盘上的卷时，转换 Arcserve UDP 代理备份会话的备用虚拟机无法检测到相应 4KB 扇区磁盘的分区和卷。源磁盘包含 4 KB 扇区，并且备用虚拟机支持 512B 扇面磁盘时，便会出现此问题。转换后，因扇区大小变化，备用虚拟机中的客户操作系统无法找到磁盘元数据。
					注意：此限制仅适用于在 Hyper-V 服务器上运行的 Virtual Standby 作业。




    

对于基于主机的虚拟机会话，如果网络适配器连接到 VM，稍后适配器断开，那么 Virtual Standby 中列出的网络适配器将比 VM 中的当前列表多。				
2TB 磁盘文件的转换失败，因为 VM 无法创建快照。
Arcserve UDP 代理 (Windows) 的磁盘为 2TB，版本低于 5.5 的 ESX/ESX (i) 服务器仅支持最大 2TB 的虚拟磁盘。不过，在转换期间，以下错误会发生：
在 vSphere Client 中：
“创建的虚拟机快照 VIRTUALMACHINE 文件 <未指定的文件名> 大于数据存储‘<未指定的数据存储>’支持的最大大小”。
“文件大于数据存储支持的最大大小”。
在 ESX/ESXi 4.x 的 hostd 日志文件中：
“快照来宾无效：文件对于文件系统过大。”
在 ESXi 5.0/5.1 的 hostd 日志文件中：
“无法执行快照操作:错误：(21) 文件对于数据存储过大。”
这是 VMware 限制。版本低于 5.5 的 VMware ESX/ESX (i) 服务器支持的最大大小是 2T-16 GB，相当于 2032 GB。
建议将 VMware ESX(i) Server 5.5 用作目标，以便对大磁盘执行转换。
有关详细信息，请参阅 VMware KB 文章 1012384。				
在 Arcserve UDP 控制台 UI 中更改虚拟备机监视器的密码并升级其节点后，使用该监视器服务器的计划部署可能会失败。
部署计划失败，并显示以下错误消息：“无法对节点“xxx”应用“备份设置”。（无法从 xxx 连接到监视器：xxx。用户凭据无效）。”
在计划中编辑虚拟备机任务，输入监视器的正确密码，然后保存计划。
					VSS 快照相关问题				
由于 VM 客户操作系统内的 VMware 或 Microsoft 所引起的 VSS 快照问题，为 VMware VM 的无代理备份生成编录可能会失败，并显示以下消息：“无法将索引块映射到正确的卷块上。发生 IndexAlloc 错误。”
运行“chkdsk”以确保客户操作系统内的数据一致性。
关闭 VM，避免在客户操作系统内发生 VSS 快照。
在关机状态下备份 VM。
					注意：此问题很少发生。有关详细信息，请参阅 VMware KB 文章 2006849 或 Microsoft KB 文章 2853247。				
Backward Compatibility Related
Data Corruption During UDP Upgrade due to Backward Compatibility
You may notice data corruption for backward compatibility of protecting UDP v5 nodes to UDP v6 RPS, it might cause data corruption on deduplication data store.
This issue does not impact if you are using one of the following options:
Performing fresh installation with Arcserve UDP v6.
Upgrading the full environment from Arcserve UDP v5 to Arcserve UDP v6 without running any backup/replication job during the upgrade,
This issue impacts if you have:
Plans to ugrade from Arcserve UDP v5 to Arcserve UDP v6
Already upgraded from Arcserve UDP v5 to Arcserve UDP v6
When do you face this data corruption:
If you are upgrading from Arcserve UDP v5 to Arcserve UDP v6, you may face this issue in the following scenarios:
If you run some failed backup/replication jobs while upgrading the full environment from Arcserve UDP v5 to Arcserve UDP v6.
If you upgrade from Arcserve UDP v5 to Arcserve UDP v6 but stay in mixed versions, data corruption may occur when a failed backup/replication job takes place.
The data corruption issue might happen in the following two scenarios.
Scenario 1: The Agent node is with Arcserve UDP v5 and the RPS node is with Arcserve UDP v6. Agent job fails to back up and generates the incomplete recovery point on the deduplication data store. Deleting the incomplete recovery point from the deduplication data store may lead to data corruption.
Scenario 2: The source RPS node is with Arcserve UDP v5 and the destination RPS node is with Arcserve UDP v6. The Replication job fails and generates the incomplete recovery point destination deduplication data store. Deleting the incomplete recovery point from the destination deduplication data store may lead to data corruption.
Reason
Due to the mismatch of interface between different versions, when Arcserve UDP v6 RPS tries to delete the incomplete sessions generated by Arcserve UDP v5, it may wrongly delete additional index files which leads to data corruption.
If you are upgrading from Arcserve UDP v5 to Arcserve UDP v6: 
Upgrade full environment from Arcserve UDP v5 to Arcserve UDP v6 without running any backup/replication jobs during the upgrade.
Upgrade from Arcserve UDP v5 to Arcserve UDP v6, and immediately apply the patch T00000360 on RPS nodes with Arcserve UDP v6. 
Note: Before applying the patch, do not run any backup/replication jobs. 
Wait for Upgrade to Arcserve UDP v6 update 1. 
Note: If you opt for this option, do not upgrade to Arcserve UDP v6. You can directly upgrade from Arcserve UDP v5 to Arcserve UDP v6 update 1. 
If you have already upgraded from Arcserve UDP v5 to Arcserve UDP v6:
Either immediately apply the patch T00000360 on RPS nodes with Arcserve UDP v6 or upgrade the full environment from Arcserve UDP v5 to Arcserve UDP v6. 
Note: Contact Arcserve Support to get the patch.
Verify the data integrity at recovery point level. If data corruption has occurred, for details refer to the details provided in how to handle corrupted recovery points.
How to handle corrupted recovery points?
You cannot recover any recovery point that is corrupted due to the backward compatibility issue as the corresponding index file is incorrectly deleted. 
To make sure that the subsequent recovery points do not depend on the corrupted recovery point, we recommend to take again full backup for the impacted node. 
In addition, other jobs related to merge job that need to read from the corrupted recovery point might continue failing even though new full backup is done.
To solve the above, we recommend to rename the node folder in the backup destination folder of dedupe data store. Add Backup as prefix to the original node name. 
For example:
NODE_NAME[1a98528f-db3c-45de-83d6-9d729815ab7d]
BackupNode_Name[1a98528f-db3c-45de-83d6-9d729815ab7d]
As a result, new folder name of the source node is created that automatically converts the recovery point as full when the specific node backs up to the data store again. 
For the renamed folder, you can perform the following options:
Click the data store to browse recovery points at the very bottom in the section for “Plan: (not protected)
Restore from it, and 
Access some recovery point that are not corrupted. 
You can select to delete the renamed node through data store UI, if all the recovery points in the renamed folder are not useful anymore. The automatic retention management of the Plan only applies to the new recovery points done after the renaming of the folder.
浏览器相关问题
如果您使用的是 Windows 10 Edge Web 浏览器，当您单击“还原”或“登录代理”时，可能无法从控制台登录 Windows 或 Linux 代理。使用其他浏览器登录。
Arcserve UDP 控制台相关问题
在“节点”视图中，如果浏览器的屏幕宽度不足，则用于选择预定义筛选的“筛选”组合框以及“筛选”文本框不会显示在浏览器中。作为变通方法，请隐藏右侧窗格或放大浏览器，以查看“筛选”组合框和文本框。
如果您使用 Arcserve UDP 控制台管理多个站点，则所有站点中的网关服务器和控制台应该能够与同一电子邮件服务器进行通讯，电子邮件报警才起作用。
如果作业正在进行并且相应代理已重新启动，则控制台不会针对正在进行的作业显示任何作业历史记录。
当您在活动的“复制到磁带”作业期间修改和保存包括“复制到磁带”任务的 UDP 计划时，Arcserve UDP 上活动的“复制到磁带”作业的作业监视器将会消失。您可以在 Arcserve Backup 管理器中检查“复制到磁带”的进度，也可以在作业完成时参阅 Arcserve UDP 控制台中的作业历史记录。
当运行自动发现时，“虚拟机管理程序”列中的 VM 信息会不断更改。
如果您有两台虚拟机（VM1 和 VM2），它们在 ESXi 主机中具有相同的 GUID ，并且这两台 VM 分别由不同 vCenter（VC1 和 VC2）管理。您将 VM1 导入到控制台（不能同时导入这两台 VM，这是因为控制台不允许具有相同 GUID 的节点）。但是，您还从 vCenter VC2 导入 VM。当自动发现运行时，它会首先连接到 VC1，按 GUID 检测 VM1，并且“虚拟机管理程序”列会更新为 VC1 的信息。稍后，当它连接到 VC2 时，它会按 GUID 检测 VM2，并且虚拟机管理程序列会更新为 VC2 的信息。
两台 VM 具有相同 GUID 的情况很少见。在最糟糕的情况下，如果发生这种情况，基于主机的无代理备份可能会备份错误的 VM，这是因为 Arcserve UDP 使用 GUID 来识别 VM。要解决该问题，您可以手动更改其中一台 VM 的 GUID。有关如何执行此操作的详细信息，请参阅《解决方案指南》中的相关主题。
控制台会显示“标识服务正在启动”消息
无法登录 Arcserve UDP 控制台。即使在登录五分钟后，该控制台也会显示以下消息：
标识服务正在启动
要解决该问题：
请打开 Windows 服务控制台，然后重新启动 Arcserve UDP 控制台服务、Arcserve UDP 管理服务。
如果问题未得到解决，请验证“UDP_HOME\Management\Bin\”目录是否已添加到 Path 环境变量中。如果尚未添加，请手动添加它，然后重新启动 Arcserve UDP 标识服务。
多个节点的快速启动作业将失败。
如果其中某个节点正在运行复制作业，则多个节点的快速启动作业将失败。
您可以等待该复制作业完成再提交快速启动作业，也可以为其他节点提交快速启动作业。
“复制到磁带”作业将会失败。
在以下情况下，“复制到磁带”作业可能会失败：
使用本地化的用户名（例如，用户名采用繁体中文）将 Arcserve UDP 代理节点添加到 Arcserve UDP 控制台。将 Arcserve UDP 代理节点备份到本地磁盘或共享文件夹。然后，添加“复制到磁带”以将恢复点从本地磁盘或共享文件夹迁移到磁带。
使用本地化的用户名（例如，用户名采用繁体中文）将 Arcserve UDP RPS 节点添加到 Arcserve UDP 控制台。将其他 Arcserve UDP 代理节点备份或复制到 RPS 的数据存储。然后，添加“复制到磁带”以将恢复点从 RPS 的数据存储迁移到磁带。
针对第一个问题，使用非本地化的用户名将 Arcserve UDP 代理节点添加到 Arcserve UDP 控制台 UI。
针对第二个问题，使用非本地化的用户名将 RPS 节点添加到 Arcserve UDP 控制台。
在 NAT 环境中修改“从远程管理的 RPS 复制”任务时，将显示意外 NAT 设备设置。
当您需要在 NAT 环境中修改相应计划时，如果该计划包含以下任务，您将在“从远程管理的 RPS 复制”任务上看到冗余的 NAT 设备设置：
任务 1 从远程管理的 RPS 复制，NAT 路由器已启用并且 IP/端口已设置。
任务 2 复制到远程站点根据任务 1 进行配置，NAT 设备已启用并且 IP/端口已设置。
当您需要修改该计划并查看任务 1 配置时，您会发现冗余的“服务器在 NAT 设备后面”选项（如果配置了“服务器在 NAT 路由器后面”选项）。如果正确提供了 NAT 路由器信息，复制作业就会成功。
当您修改冗余的计划时，您可以忽略“从远程管理的 RPS 复制”任务上的“服务器在 NAT 设备后面”字段。使用“服务器在 NAT 路由器后面”字段可确保复制作业成功。 
Arcserve UDP 用户管理控制台相关问题
由于第三方组件中的某些错误，Arcserve UDP 用户管理控制台上某些对话框中的一些文本未本地化。
Arcserve UDP 用户管理控制台允许您使用特殊字符（如 [email protected]#$%^&*\ 及其他字符）创建角色名称。但是，您不能重命名、分配或删除此类角色。
Arcserve UDP 代理 (Linux) 相关问题
如果您在 Google Chrome 中打开 Arcserve UDP 代理 (Linux)，则作业状态选项卡中的行将不会与相应的列标题对齐。
不支持加密的卷。您不得备份加密的卷。
BMR 不支持 FakeRAID。如果您的备份节点是 RHEL 6.4 及更高版本、CentOS 6.4 及更高版本或 Oracle Linux Server 6.4 及更高版本且备份节点包括 Linux Software RAID，那么您必须使用基于 CentOS 的 Live CD 从此恢复点执行 BMR。
使用 RHEL 6.x 或 CentOS 6.x D2D 服务器从 RHEL 5.x 或 CentOS 5.x 恢复点中还原文件时，一些 SELinux （安全增强的 Linux）属性可能不会得到还原。
将两个安装软件包文件下载到本地文件夹时，此本地文件夹的完整路径不得包含任何特殊字符，除空格外，且路径仅应包括以下字符：a-z、A-Z、0-9、 - 和 _。
如果您使用本地作为备份目标，提交文件级还原作业或 BMR 作业，在此之后，如果要将备份目标修改为 NFS 共享或 CIFS 共享，则必须首先将 NFS 共享或 CIFS 共享添加到备份存储中。添加 NFS 共享或 CIFS 共享之后，打开“还原向导”并从“会话位置”下拉列表中选择“NFS 共享”或“CIFS 共享” ，然后重新提交该作业。
Oracle Linux 仅支持 Red Hat 兼容内核。您必须选择 Red Hat 兼容内核作为默认启动内核。Oracle Unbreakable 内核不被支持，并且它不应当是默认启动内核。
如果您使用 Live CD 在 Citrix XenServer 6.x 中启动 PVM，Arcserve UDP 代理 (Linux) 备份服务器将在 Live CD 中不可用。
备份相关问题
升级到 Windows 10 后，系统会删除卷的跟踪驱动程序高层筛选。BLI 驱动程序无法跟踪卷中的任何更改。因此，增量备份作业将转换为验证备份作业。
卷类的注册表 BLI 高层筛选将被删除。因此，BLI 驱动程序无法监视卷。
您可以在重新安装更改跟踪驱动程序后继续执行增量备份。
					请按照下列步骤操作：				
通过从以下路径运行 UninstallDriver.bat 文件，卸载更改跟踪驱动程序。
<安装路径>\Arcserve\Unified Data Protection\Engine\BIN\DRIVER
通过从以下路径运行 InstallDriver.bat 文件，重新安装更改跟踪驱动程序：
<安装路径>\Arcserve\Unified Data Protection\Engine\BIN\DRIVER
操作基于 COM 的组件（如 VSS、VDS）时，备份、还原或 BMR 信息收集可能会失败。事件 ID 10006、1503 或 6287 可能会显示在 Windows 事件日志中。
日志事件中可以找到以下消息：“试图在标记为删除的注册表项上进行非法操作”或“Windows 检测到注册表文件仍在由其他应用程序或服务使用。此文件即将卸载。包含注册表文件的应用程序或服务之后可能无法正确运行。”
有关原因和解决方案，请参阅 Microsoft KB 文章 2287297。				
挂接卷失败，出现消息“无法将恢复点挂接到路径:“Z:”.功能错误。”				
将会话挂接到驱动器号失败。
当目标为 FAT32 卷上的本地文件夹时，将发生此问题。挂接驱动程序仅支持在 NTFS 卷上创建缓存文件。
添加新的注册表项，并将缓存文件自定义至其他卷上。
					请按照下列步骤操作：				
在 HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine 上创建注册表项“AFStorHBAMgmt”。
创建字符串值“CacheFilePath”。
					更多信息：				
挂接可写卷后，将通过挂接驱动程序创建缓存文件。为粒度还原编录/还原作业创建了可写卷。如果会话备份 Windows 8、Windows 2012 或更高版本操作系统上的卷，当您将会话挂接到驱动器号时，将始终挂接可写卷。
从 Arcserve UDP 代理 (Windows) UI 提交备份作业时，如果备份目标正在使用恢复点服务器上的数据存储，备份作业可能不会启动。
显示备份提交成功，但 Arcserve UDP 代理 (Windows) UI 中看不到任何作业监视器。这是因为备份作业达到数据存储中的最大并行节点计数设置。备份作业将置入等待队列。
打开 Arcserve UDP 控制台，挂起的作业监视器将显示在节点视图上。				
如果备份作业运行时重新启动 Arcserve UDP 代理 (Windows) 计算机，作业将在 Arcserve UDP 代理 (Windows) 主页上标记为“崩溃”，但是 Arcserve UDP 控制台上没有此作业的作业历史记录。这是因为作业结束时，作业历史记录项目将发送到 Arcserve UDP 控制台，但如果重新启动，则无法将作业历史记录从代理发送到服务器。				
作业监视器上基于主机的无代理验证备份作业的压缩百分比不正确。 
基于主机的无代理验证备份作业正在运行时，如果已在计划中启用压缩，则作业监视器上显示的压缩百分比将高于实际百分比。
所有其他备份作业无此问题，包括代理备份作业和基于主机的无代理完全/增量备份作业。
活动日志中输出的压缩百分比是正确的。在基于主机的无代理验证备份作业完成后引用此百分比。				
VMware VM 备份作业会成功完成，但生成转储文件。
VMware VM 的备份作业会在 Arcserve UDP 控制台上成功完成。该作业使用绿色图标进行标记，并且活动日志会显示“备份作业已成功完成”消息。但是，系统将在 BIN 文件夹中的代理安装路径下生成后端进程转储文件（如 AFBackend.exe.7912.00.dmp）。例如：C:\Program Files\Arcserve\Unified Data Protection\Engine\BIN。
发生这种情况是由于 VMware VDDK 的问题，因为有时 VDDK 会在 Arcserve UDP 关闭对 VDDK 的 API 调用时崩溃。您可以忽略此问题，因为这种情况发生在备份作业的最后一个阶段。这时，备份作业几乎已完成，并且恢复点已成功结束。
BMR 相关问题
创建启动工具包失败，出现以下错误：
“无法将语言包集成到 BMR ISO 映像”。
此问题由第三方防病毒软件（McAfee）筛选驱动程序引起，但在使用其他第三方筛选进也会发生。
禁用您的防病毒软件并重新尝试启动工具包创建。				
无法在执行 BMR 之后启动服务器。
源计算机是向配有不同硬件的物理计算机或 Hyper-V 服务器上的虚拟机执行 BMR 的 Active Directory 服务器时，该服务器不启动，并显示蓝屏，出现以下消息：
停止：c00002e2 因为以下错误，目录服务无法启动：连到系统上的设备没有发挥作用。错误状态：0xc0000001。
将系统重新启动到 BMR PE 环境，重命名 C:\Windows\NTDS 文件夹中的所有 *.log 文件，然后重新启动系统。例如，将文件 edb.log 重命名为 edb.log.old，然后重新启动系统。				
无法在 BMR 期间将源磁盘映射到目标磁盘，即使两个磁盘的大小恰恰相同。
目标计算机是 2008 Hyper-V 服务器或 2008R2 Hyper-V 服务器上具有 IDE 磁盘的 VM 时，您在 BMR 期间可能无法映射磁盘/卷。
如果您使用 BMR 将数据还原到 2008 Hyper-V 服务器或 2008R2 Hyper-V 服务器上具有 IDE 磁盘的 VM，则无法将源磁盘/卷映射到目标磁盘/卷，即使两个磁盘的大小相同也是如此。这是因为您在 2008 Hyper-V 服务器或 2008R2 Hyper-V 服务器上创建 IDE 磁盘时，实际磁盘大小小于您指定的大小。
在 VM 上创建更大的磁盘。例如，如果您想从 25 GB 的磁盘还原数据，建议在目标 VM 上创建 26 GB 的磁盘。				
如果使用 Windows ADK 8.1 创建 BMR ISO，则在使用此 ISO 启动计算机之后，您可能发现 PE 系统中没有检测到磁盘。
此问题出现在 VMware ESX Server 上。对于 Windows 2003 VM，默认的磁盘控制器为 LSI Logic SCSI 适配器，且 Windows ADK 8.1 不包含这种 SCSI 适配器的驱动程序。在某些带有旧版 SCSI 适配器的旧版服务器上也可能出现此问题。
要解决此问题，请从硬件供应商网站获得驱动程序，并从 BMR 用户界面加载相应驱动程序。				
硬件快照相关问题
如果 VMware VM 备份作业使用硬件快照，将在调试日志中显示多条以下消息。多条消息会增加安装 Arcserve UDP 的卷的磁盘空间占用。我们正与 NetApp 合作解决此问题。
					[VDDKLOG] SSLCheckLockingCallback: locking callback overwritten!Expected 7FEE3A836E0, saw 113C2420				




    

作为变通方法，请将以下路径中的 VDDKLogLevel 注册表项设为 0：
\HKEY_LOCAL_MACHINE\Software\Arcserve\Unified Data Protection\Engine\
CSV 可传输快照有时可能失败，并恢复为软件快照。在硬件提供方多次重新尝试创建可传输快照后，会发生这种情况。您可以在 Windows 事件查看器中找到以下错误。我们正与 NetApp 合作解决此问题。
					在以“10”秒的时间间隔重试“100”次后，无法跨存储系统“xxx”的多个卷创建快照副本“{xxx}_backup”。				
对于 cDOT 的当前 Data ONTAP 版本，硬件快照使用 FlexClone（即使它未获得许可）。这是一个已知的 NetApp 问题。要继续备份而不使用 FlexClone 许可，请在 Arcserve UDP 代理服务器上创建注册表项。
					按照以下步骤创建注册表项：				
登录到代理服务器。
在以下位置创建 DoNotUseFlexCloneLicenseToCloneLun 项：
HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine
创建以下字符串值，并将该值设置为 1。
DoNotUseFlexCloneLicenseToCloneLun
在切换到 Arcserve UDP 恢复点视图后，挂接在备份会话中文件路径下的卷将无法被挂接。
如果卷仍被挂接，Arcserve UDP 恢复点视图会直接打开操作系统挂接的卷，而不是备份会话挂接的卷。
如果卷被卸载，在该文件路径下的 Arcserve UDP 恢复点视图中将不显示任何内容。
使用“挂接恢复点”挂接此种卷。				
Host-Based VM Backup Related
Potential problem detected when backing up a VMware VM with Changed Block Tracking enabled and running on ESXi 6.0 or ESXi 6.0.
VMware recently published a KB article, which indicates that, in ESXi 6.0 or ESXi 6.0.x, a bug has been introduced in Changed Block Tracking (CBT) and it causes the CBT to return incorrect changed sector list. Arcserve UDP is potentially affected by this issue, which results inconsistent virtual machine backups (both full and incremental). For more details, refer to the VMware KB.
If the problem occurs, the catalog job may fail and Check Recovery Point may report errors. 
VMware has released a patch for this issue. Apply this patch on your ESXi hosts. For more details, see the VMware KB article, or Arcserve KB article.
An agentless backup of SUSE Linux Enterprise Server 12 VM in Hyper-V fails and VM guest OS hangs after the backup.
This problem is observed if the Hyper-V host is Windows 2012 R2 and VM’s guest OS is SUSE Linux Enterprise Server (SLES) 12 with runlevel 5 (with graphical interface). In this case, the agentless backup job hangs at the “taking snapshot” phase and finally fails. After that, the VM guest OS becomes unresponsive.
This is not an issue of Arcserve UDP but a compatibility problem of Windows and SUSE. The same problem occurs when creating a VSS snapshot by using diskshadow command in the Hyper-V host. Follow these steps to verify the problem:
Log in to the Hyper-V server.
Open the Windows Command Line as an administrator.
From the command line, type the following commands.
Type "diskshadow" and press Enter.
Type “add volume X:” and press Enter. (X: is the volume in which VM’s virtual disk files and configuration file reside. If VM’s disk files or configuration file are on different volumes, repeat this command to add all the volumes.)
Type "create" and press Enter.
After the snapshot creation finishes (this may take some time), type "end backup" and press Enter.
Type "exit" and press Enter.
Check if VM guest OS hangs.
Check the Windows Event Log, Applications and Services Logs, Microsoft, Hyper-V VMMS, Admin. There should be one error log which indicates the failure of the VM during the snapshot creation.
There is no workaround so far. We suggest you to work with Microsoft to solve the root cause. Alternatively, you may try changing the runlevel of SLES 12 from 5 to 3 (without graphical interface) but this does not guarantee any resolution.
Pre-flight check (PFC) reports “failed to access the virtual machine” for VMware VM
For VMware VM, pre-flight check (PFC) reports the following warning message for the Data Consistency check even when you have already provided proper credentials.
Not verified because the application failed to access the virtual machine. Verify that the user credentials are correct and have administrative privileges. 
Only PFC for VMware VM has this issue. Other features such as backup are not affected. The workaround is to install Arcserve UDP Agent on the machine in which Arcserve UDP Console is installed (Agent service does not have to be started).
Backup and restore using SAN transport failover to non-SAN transport mode for VMs residing on ESXi 5.5 or earlier
Even when a SAN transport mode is possible, backup and restore jobs still use the HotAdd, NBD, or NBDSSL transport mode.
This is a known issue of VMware VDDK 6.0.1. There is no solution from VMware for now. For details you can refer to Know Issues in VDDK 6.0.1 release notes.
Backup and restore using SAN transport failover to non-SAN transport mode when the provisioned size of VM’s virtual disk is 4 TB or a multiple of 4 TB
Even when a SAN transport mode is possible, backup and restore jobs still use the HotAdd, NBD, or NBDSSL transport mode when the provisioned size of VM’s virtual disk is 4 TB or a multiple of 4 TB.
This is VMware known issue which, according to VMware, has been in following patches:
•	For ESXi 5.5 - Patch Release ESXi550-201504001 (2112672)
•	For ESXi 6.0 - Patch Release ESXi600-201505001 (2116125)
The workaround is to avoid using provisioned size which is the multiple of 4 TB. For example, do not use 4 TB or 8 TB; instead, use 3.9 TB or 8.1 TB.
When VMware Tools snapshot quiescing method is used, an agentless backup of VMware systems back up a corrupted snapshot.
When you quiesce a VMware VM using VMware Tools, the snapshot contains corrupted data. The backup reads data from the snapshot and the data that is backed up also becomes corrupted. For more information about this issue, see the VMware KB article.
Note: This problem occurs with all VMware ESXi versions and on a VM with guest OS Windows 2008 R2 SP1 and Windows 2012. Arcserve UDP cannot detect the data corruption problem because VMware does not return an error in this case. You may not be aware of the problem until you try to restore data.
Perform the following tasks to detect and resolve the problem:
Recovery Point Check - Mount the volumes from the recovery point and verify data consistency by running the Microsoft tool CHKDSK at the end of the backup job. For more information on the chkdsk tool, see the Arcserve UDP Solutions Guide. The chkdsk tool may take a longer time to run. As a best practice, enable this option for weekly or monthly backup jobs.
Disable problematic writers in the guest OS of the VM - If the Recovery Point Check detects a problem, perform the steps described in "How to check if you may be affected by this bug" in the Arcserve KB article. The workaround suggested by VMware is to disable the VSS writers MSSearch Service Writer (ignore it, if not installed) and Shadow Copy Optimization Writer (typically present in every Windows VM) in the guest OS of the VM. You can manually do this per the VMware KB article. Arcserve UDP also provides a simple way to disable the problematic writers during a backup. For details on this known issue, see File System Catalog job fails or Recovery Point Check fails for Host-Based Agentless backup topic in the Troubleshooting chapter of Solution Guide.
The Microsoft VSS Inside VM snapshot quiescing method in a VMware VM may results an inconsistent backup
When using the Microsoft VSS inside VM snapshot quiescing method to back up a VMware VM, the backup may not be consistent. Especially when backing up VM with applications (such as Exchange) installed.
The workaround is to use VMware Tools snapshot quiescing method, along with disabling the VSS writers MSSearch Service Writer and Shadow Copy Optimization Writer in guest OS of VM  before this problem gets fixed.
After recovering a clustered VM to the original Hyper-V cluster, the network adapter could not connect to the virtual switch and displayed a warning message in the activity log:
Unable to connect the network adapter <<adapter name>> to the virtual switch.
When backing up a VM, failover happens for the clustered VM before taking a snapshot . This failover causes the Hyper-V host that is recorded in the backup session to be inconsistent with the VM configuration.
You can manually connect the network adapter to a virtual switch on the Hyper-V host or use the Restore to an alternative location option to recover the VM that lets you set the restore configuration for the VM.
In Hyper-V 2012 or later, the virtual machine stays in the “Backing up” status although the agent-less host-based backup job of this virtual machine has already finished.
Although the backup job of one virtual machine has already finished, the virtual machine's status is still "Backup up" in the Hyper-V Manager. Therefore, if another backup job for this VM starts at this time, it will fail with error "The Hyper-V VSS writer has encountered an error when processing this virtual machine". In addition, you cannot perform some operations, such as power on/off, for the VM at that time in the Hyper-V Manager. If the VM is a Hyper-V cluster, you cannot perform live migration for that VM.
This problem happens during the following situations:
There are several backup jobs starting at the same time or at times close to each other (within 1 minute).
One or more backup jobs finished, but there is still at least one backup job which is still in progress.
While the VM is "locked", you can still use the guest OS as normal. Therefore, this has no impact on the usage/availability of the guest OS. However, if you have concerns and want to avoid this situation, you can do either of the following:
Use the Hyper-V Snapshot Separation option on the resources tab of agent-less host-based backup. For more information, see the Arcserve UDP Solutions Guide.
Use different plans to protect VMs which have a different size. In other words, include the VM with a similar size in one plan so that those backup jobs take a similar amount of time and, at the same time, set different schedules for those plans.
When you perform Incremental backup jobs for VMware virtual machines, the backed up data size of the Incremental backup jobs may be larger than expected.
This is a known VMware issue where it involves Changed Block Tracking (CBT). With application level quiescing, Changed Block Tracking overstates changes.
The issue is fixed in VMware ESXi 5.5 or later, and in VMware ESX 5.1 Patch 02. If VMware vCenter Server 5.5 manages any VMware ESXi 5.1 hosts, then the patch should be applied to them. For more information on this fix, see the VMware KB.
If you still see the issue, then set the following registry on the proxy server: 
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\<VM instance UUID>]
"ResetCBT"=dword:00000001
Example:
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\502d3c43-e3c9-9919-78f9-89082ca5e1cc]
"ResetCBT"=dword:00000001
Note: After the registry value is set, the next Incremental backup job converts to a Verify backup job and then the subsequent Incremental backup jobs continue to run with the appropriate size. 
Due to a VMware known issue, when the storage DRS is enabled and the storage vMotion occurs while the backup job is in progress; the backup job can fail. The activity log specifies the following message: "Unable to open the VMDK file." VMware reported the following error: "A file was not found."
For more information, see the VMware KB Article 2055943.
The recovery of a VM with VMDK larger than 2-TB of disk fails because the VM failed to create a snapshot.
The backup source VM has VMDKs larger than 2-TB and the ESX/ESX(i) server with a version lower than 5.5 can only support a virtual disk of up to 2-TB disk in size. However, during the VM recovery, the following errors can occur:
In the vSphere Client:
"Create virtual machine snapshot VIRTUALMACHINE File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>'".
"File is larger than the maximum size supported by datastore".
In the hostd log file for ESX/ESXi 4.x:
"Snapshot guest failed: The file is too big for the file system."
In the hostd log file for ESXi 5.0/5.1:
"Failed to do snapshot op: Error: (21) The file is too big for the datastore."
This is a VMware limitation. The maximum size that VMware ESX/ESX(i) server version lower than 5.5 supports is 2 T-16 GB, which is equal to 2032 GB.
It is recommended to use VMware ESX(i) server 5.5 as the destination to perform conversion with a large disk.
For more information, see the VMware KB Article 1012384. 
Creating a snapshot fails when more than seven disks are attached to a single SCSI controller for a Windows VM running on an ESXi server.
When you run a backup job on a virtual machine containing a SCSI controller with more than 7 VMDKs, the backup job fails. The backup job fails because VMware requires a maximum number of free slots for VMDKs on a particular SCSI controller to create a snapshot. A SCSI controller can have a maximum number of 15 slots. For example, if a SCSI controller has 7 VMDKs, a snapshot can be created for each VMDK. (A total of 14 slots are used with one slot free.) If a SCSI controller has 8 VMDKs, the backup job fails because the snapshot cannot be created due to only 15 available slots.
Note: Manually creating a snapshot also fails.
For virtual machines with more than seven disks on a single SCSI controller, perform the following steps:
Shut down the virtual machine.
Create more thin virtual disks which allow you to add more SCSI controllers.
Distribute the existing disks between multiple SCSI controllers.
Power on the virtual machine.
Snapshots can now be created for each VMDK.
This issue is a VMware limitation where Arcserve Backup can only support the number of VMDK disks for backups.
For more details, see the following VMware Knowledge Base article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2015181 
When you import VMware virtual machines from vCenter Server/ESXi 5.0 Update 3 and above while using HTTP protocol and port 80, the connection fails.
This is a known issue with VMware. The following link opens the VMware KB article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2069149 
When a VM is imported from a Hyper-V server, the VM becomes disabled after the Host-Based Agentless Hyper-V VM restore job overwrites the VM. The VM is disabled because the instance GUID of the restored VM is different from the original instance GUID, which was imported from the Hyper-V server. The VM instance GUID cannot revert to the original instance GUID.
To resolve this issue, remove the old VM from Central Protection Manager and import the new VM. 




    

An ESX/ESXi/vSphere 5.5 purple screen of death appears when an Arcserve UDP job runs.
This is a known VMware issue affecting ESXi 5.0, 5.1, and 5.5 hosts and virtual machines using the E1000 and E1000e virtual network adapters.
Note: This issue is resolved in the following VMware updates.
ESXi 5.0 Patch Release ESXi500-201401001. For more information, see the VMware KB.
ESXi 5.1 Update 2, available at VMware Downloads. For more information, see the VMware KB.
ESXi 5.5 Update 1, available at VMware Downloads. For more information, see the VMware ESXi 5.5 Update 1 Release notes.
ESXi 6.0 GA, available at VMware Downloads. For more information, see the VMware ESXi 6.0 Release notes.
Switch to a VMXNET3 adapter. For more information, see the VMware KB Article 2059053.
During backup, the Arcserve UDP agent merges the child disks data to the corresponding parent disk and creates a single disk image. Therefore, the parent-child relationship no longer exists after VM backup. As a result, only the parent disk is recovered and the "differencing disks" configuration is lost, however no data is lost. You can retrieve the data in a single merged disk after VM recovery.
This behavior is expected for agentless backup. You can configure the "Differencing disks" manually after a successful VM recovery. 
Import VM fails when duplicate VM instance UUID exists. 
When a VM is imported to the node view, it fails if another VM with same VM instance UUID is already added to the node view.
A host-based VM backup plan is saved, it fails when the selected proxy machine is installed with Arcserve D2D r16.5. 
When a host-based VM backup plan includes a proxy machine that has the previous release of Arcserve D2D installed (for example, r16.5), the error message “Cannot find dispatch method” appears when the plan is saved.
This problem occurs because the API of the current version is not compatible with the API of the previous version of Arcserve D2D. As a work around, you can manually upgrade Arcserve D2D to the current version of the Arcserve UDP 代理 (Windows).
The host-based VM backup job may hang at the phase "Starting Backup" for a VM. 
The host-based VM backup job hangs for hours and cannot proceed.
End afbackend.exe according to the process ID in the activity log, remove the VM snapshot if any, and resubmit the backup job.
After performing a restore job for a host-based VM backup Hyper-V virtual machine (VM), the status of the disks, except the boot disks on the recovered virtual machine is Offline. 
The behavior of the operating system creates the offline state by default.
The SAN policy was introduced in Windows Server 2008 to protect shared disks that are accessed by multiple servers. The default SAN policy from the source VM is “Offline Shared” for all SAN disks except the boot disk. Setting the policy to Offline enables the SAN disks to be offline during startup. After recovery, a new disk for the VM is created. The disk file from the VM appears to be a SAN disk where the operating system identifies it as being offline. When the offline disk is set to be back online, the disk remains online even after rebooting the system.
As a workaround, specify the DISKPART.exe command: SAN POLICY=OnlineAll setting for the source VM before backup. Because the disks can be shared among other servers, data corruption can occur. You must use the correct SAN policy to protect the data.
DISKPART.EXE command line
Query SAN policy:
DISKPART > san
SAN Policy: Offline Shared
Change SAN policy:
DISKPART > san policy=OnlineAll
DISKPART successfully changes the SAN policy for the current operating system.
The iSCSI hard disk that is attached to a Hyper-V virtual machine will not be backed up.
After backing up a Hyper-V VM, the volumes on iSCSI devices are not listed in the restore UI.
Create an agent-based backup plan in Arcserve UDP or use Arcserve UDP 代理 (Windows) to back up the virtual machine. 
Pre/Post commands cannot be executed by host-based agentless backup jobs on a Hyper-V VM when the guest operating system is Windows Server 2003.
For host-based agentless backup jobs for a Hyper-V VM, if the guest operating system is Windows Server 2003, the Pre/Post commands cannot be executed. The activity log prints the warning "The virtual machine name is not expected. Pre/Post commands cannot be executed".
Windows Server 2008, Windows Vista, or a later version of operating system do not have this problem and should be used. 
At times backup job for VMware VM crashes when the backup proxy is Windows 2003 R2 64-bit machine.
When Windows 2003 R2 64-bit machine is used as the backup proxy server to protect VMware VM, at times the backup job may crash. You can see error messages as following in the backup job debug log file:
[2016/01/21 10:18:11:316   00   03820   03336             ] [VDDKLOG] VixDiskLib: VixDiskLib_OpenEx: Open a disk.   {AFBackend.exe::AFBackupVirtual.dll(1746.0)}
[2016/01/21 10:18:11:316   00   03820   03336             ] [VDDKLOG] VixDiskLibVim: VixDiskLibVim_GetNfcTicket: Get NFC ticket for [datastore1 (3)] VMname/VMware_1.vmdk.   {AFBackend.exe::AFBackupVirtual.dll(1746.0)}
[2016/01/21 10:19:11:691   00   03820   03336             ] [VDDKLOG] VixDiskLibVim: Error 18000 (listener error GVmomiFaultInvalidResponse).   {AFBackend.exe::AFBackupVirtual.dll(1746.0)}
[2016/01/21 10:19:11:691   00   03820   03336             ] [VDDKLOG] VixDiskLibVim: Login failure. Callback error 18000 at 2439.   {AFBackend.exe::AFBackupVirtual.dll(1746.0)}
[2016/01/21 10:19:11:691   00   03820   03336             ] [VDDKLOG] VixDiskLibVim: Failed to find the VM. Error 18000 at 2511.   {AFBackend.exe::AFBackupVirtual.dll(1746.0)}
In Arcserve UDP Version 6.0, VMWare VDDK 6.0.1 is built in. But VDDK 6.0.1 does not officially support Windows 2003 R2. As a workaround, you can use one of the following options:
Switch to use a proxy that is officially supported by VDDK 6.0.1. For example, proxy with Windows 2008 R2, Windows 2012 or Windows 2012 R2.
Replace built-in VDDK 6.0.1 by VDDK 5.5.5, which is also supported by UDP 6.0. For details on how to replace VDDK, refer to the following topic in Arcserve UDP Solution Guide v6.0:
How to apply different version of VDDK other than the built-in Version (6.0.1) in Arcserve UDP
即时 VM 的名称和位置与预期结果不同。
当您使用 ESX 信息登录并选择资源池作为即时 VM 的位置时，即时 VM 位于 ESX 主机下方，并且不在此资源池中。如果您从控制台删除此即时 VM，并使用同一名称重新创建一个即时 VM，则它将在此即时 VM 的名称（而不是时间戳）中添加后缀 (1)，这不符合预期。
这是因为 ESX 服务器由 vCenter 管理。使用 vCenter 登录信息创建即时 VM。
如果您创建无代理备份计划，并指定本地路径作为备份目标，则不能从此类恢复点创建即时 VM。要解决此问题，请使用共享文件夹作为备份目标。
如果您使用 IP 地址添加节点，接着创建备份计划，并指定共享文件夹作为备份目标，则可能不会从节点列表视图中创建即时 VM。不过，您可以从目标视图中创建即时 VM。或者，您也可以使用主机名更新节点，并尝试再次创建即时 VM。
如果恢复点具有已镜像的系统卷，而您使用该恢复点创建即时虚拟机（即时 VM），则可能会遇到一些错误，如黑屏死机。
重新启动恢复服务器后，无法在 Hyper-V 中启动即时 VM
当我启动即时 VM，然后重新启动 Hyper-V 恢复服务器时，即时 VM 可能无法启动。
要解决此启动故障，请重新启动即时 VM。
在 Windows Server 2012 中，在动态磁盘上创建 NFS 可能会失败。要避免此问题，请使用基本磁盘。您还可以应用修补程序来解决此问题。有关该修补程序的详细信息，请参阅 Microsoft 中的 KB 文章。				
当对用作恢复服务器上的 VMware NFS 的 Windows 卷进行格式化时，即时 VM 创建会失败。
我已指定 Windows 卷作为 NFS 共享文件夹，并将该共享卷的路径提供为即时 VM 文件路径。当我格式化 Windows 卷，然后尝试创建即时 VM 时，将无法创建即时 VM。无法创建即时 VM 的原因是 ESXi 主机无法添加 NFS 数据存储。VMware 显示以下错误消息：
VMware 创建 VM 失败。
vmkernal.log 文件中显示以下错误日志：
No underlying device for major, minor
要解决该问题，请在恢复服务器上执行以下步骤：
依次打开“控制面板”、“系统和安全”、“管理工具”。
此时打开“管理工具”对话框。
双击“服务”。
此时将显示“服务”对话框。
右键单击“NFS 服务器”，然后单击“停止服务”。
右键单击“NFS 服务器”，然后单击“启动服务”。
再次使用该卷创建即时 VM。
该即时 VM 得以创建。
日志视图相关问题
节点名称为“VM（主机名称）”且通过单击查看日志链接加载日志视图时，日志筛选不起作用。
在日志视图中，如果受保护的 VM 没有主机名，则其节点名称值显示为“VM（节点名称）”。在这种情况下，其他筛选不起作用。
您可以将节点名称从“VM （主机名称）”手工修改为“主机名称”，然后所有筛选都将正常运作。例如，将节点名称 “VM (xxxxx01-AB)”改为“xxxxx01-AB”。				
安装/远程部署相关问题（代理）
安装挂接驱动程序失败，在调试日志中错误代码 1460。
Windows 安装程序 API 报告错误 1460，即意味着超时时段到期。默认超时值是 300 秒，用于更新设备驱动程序。
要调整超时值，请执行以下步骤：
在“开始搜索”框中键入 gpedit.msc 并按下 Enter 键。
出现 UAC 提示时，单击继续。
导航到以下策略位置：
Computer Configuration\Administrative Templates\System\Device Installation
启用以下策略设置：
配置设备安装超时。
指定新的超时值，以秒为单位。				
Microsoft Exchange 相关问题
Exchange 数据库还原失败，错误如下：“无法安装"。
Exchange 服务器已安装在 VM 中，且运行 Arcserve UDP 代理 (Windows) 保护此 VM 时会发生该问题。备份运行一段时间后，如果 VM 恢复为先前保存的 VM 快照，而您尝试将 Exchange 数据库恢复到原始位置时，还原将失败，并显示错误“Exchange 存储组/数据库 [数据库名称] 已还原到其原始位置，但无法挂接”。
根本原因仍在调查中，但是目前似乎与 Exchange 数据库和最新事务日志文件内记录的时间戳有关。
尝试将 Exchange 数据库恢复到备用目录，或在执行还原之前卸载数据库并删除目标文件夹中的所有文件。				
Microsoft SQL Server 相关问题
如果 Microsoft SQL Server 无法分配更多内存，Arcserve UDP 控制台可能响应较慢。
Microsoft SQL Server 可能需要分配更多的内存来处理查询，尤其是当 Arcserve UDP 数据库中存在过多数据时。但是，如果由于内存不可用或配置的最大限制导致 Microsoft SQL Server 无法获取内存，那么查询处理将变得非常慢，进而影响 Arcserve UDP 控制台的响应速度。
使用日志/删除删除数据库中的一些日志，然后重新启动 SQL 服务。				
恢复点服务器 (RPS)/数据存储相关问题
手动合并作业不会执行，并显示错误
手动提交合并作业时，该作业不会运行，并且在活动日志中显示以下消息：
无法运行 <节点名称> 的合并作业，另一作业正在运行
出现该错误的原因可能是，存在该节点的其他作业正在同一恢复点服务器但不同数据存储中运行。作为变通方法，请等待这些作业完成，然后重试。
防病毒软件意外删除数据存储文件。
备份或复制作业失败，错误为“系统找不到指定的文件”。
检查 Windows 事件日志。McAfee 将数据存储文件（例如 P0000000042.data）检测为 Exploit-ScriptNull 木马病毒并将其删除。
配置防病毒设置，在排除列表中设置恢复点服务器 (RPS) 数据存储的位置。
					注意：某些防病毒软件要求您在服务器端设置排除列表。				
目标为重复数据消除的数据存储时，取消复制作业可能需要几分钟时间。
将网络限制设置为很低的带宽或目标 RPS 服务器的网络吞吐量较慢时，会发生这种情况。因此，可能需要等待几分钟时间，才能发送排队的数据。
等待复制作业正常退出。				
如果存在以下两种状况，修改数据存储时，数据存储的哈希内存显示不正确。
RPS 服务器的内存小于等于 4 GB。
创建数据内存时，未选择哈希内存的最大值。				
恢复点服务器 (RPS)/从 Hyper-V/相关节点导入
尝试按 IP 地址或节点名称添加节点时，可能发生“需要管理员权限”错误并阻止您添加节点。尝试从 Hyper-V 导入时，“请检查帐户是否对 Hyper-V 服务器有管理员权限”错误会发生，并阻止您导入虚拟机。
尝试在支持用户帐户控制 (UAC) 的 Windows 操作系统（Windows Vista 或更高版本）上按 IP 地址或节点名称添加节点或尝试从支持 UAC 的 Hyper-V 服务器导入虚拟机时，如果使用的新 Windows 用户帐户是在管理员组中的本地帐户，而不是内置管理员，则会显示以下消息：
“需要管理员权限。”
使用内置管理员或域管理员。或者，您可以禁用远程 UAC。
这是称为“UAC 远程限制”的默认 Windows 行为。如果您仍想使用此帐户来添加节点，请执行以下步骤禁用远程 UAC：
单击“开始”，在“搜索程序和文件”字段中键入 regedit，然后按 Enter 键。
此时将打开 Windows 注册表编辑器。
					注意：您可能需要提供管理凭据，才能打开 Windows 注册表编辑器。
查找并单击以下注册表项：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
从“编辑”菜单，单击新建，然后单击 DWORD (32 位) 值。
指定 LocalAccountTokenFilterPolicy 作为新条目的名称，然后按 Enter 键。
右键单击 LocalAccountTokenFilterPolicy，然后单击“修改”。
在“值”数据字段中指定 1，然后单击“确定”。
退出注册表编辑器。
有关 Windows 行为的详细信息，请参阅文章 http：//support.microsoft.com/kb/951016。				
无法为节点删除指定的管理程序。
此版本未提供为节点删除管理程序的功能。
删除节点然后重新添加。				
尝试将已由某个控制台管理的节点添加到其他控制台时，不显示警告或弹出消息。
利用 Arcserve UDP 的一体化 UI，用户不会有多个 Arcserve UDP 控制台，因此仅在旧服务器无法使用时，才会出现将代理从一个服务器移至另一服务器的情况。
将节点从一个控制台移至另一控制台的情况很少出现。				
注册表相关问题
如果备份目标是 Windows Server 2012 上启用重复数据消除的 NTFS 卷，且 Arcserve UDP 代理 (Windows) 安装在 Windows 2003 上，还原、合并或编录作业可能失败。该作业失败，出现 Windows 错误代码 50 和消息“不支持该请求”。
将 McAfee 或其他第三方软件安装在 Windows Server 2012 上时，它们会在注册表中设置 EnableECP=1。
在注册表中，在以下注册表项下将 EnableECP 的值从 1 更改为 0：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanManServer\Parameters
有关详细信息，请参阅 http://support.microsoft.com/kb/2817216。				
复制相关问题
在复制源端中止 RPSReplication.exe 进程可能导致第二个复制作业失败。
第二个复制作业将以准备状态挂起，并于 10 分钟后失败。
您不需要执行任何特定操作。第二个复制作业失败后，将触发补充作业。				
直到文件复制作业完成才能运行复制作业。
复制作业会失败，并且活动日志会显示“无法锁定 <path> 上的会话。会话已被文件复制作业锁定，计算机名：<name>，进程 ID <ID>”。如果在启用文件系统编录作业的情况下运行备份，并且您将文件复制作业配置为从复制目标数据存储运行，则会发生此情况。
文件复制作业会锁定该会话，因此复制作业无法运行。要解决此问题，您可以使用以下任一选项：
为文件复制作业配置适当的排定，以使其按时运行，从而允许复制作业运行。或者
在计划中禁用文件系统编录。
Arcserve UDP Exchange Granular Restore (AEGR) 实用工具相关
当使用 Arcserve UDP Exchange Granular Restore 实用工具时，所有项目均不会还原到活动服务器。
还原作业之后，以下项目属性可能无法正确还原：
InternetHeaders
RTFCompressed
Codepage
DateCompleted
TaskRecurrence
RecurrencePattern
AppointmentTimeZoneDefinitionEndDisplay
ReminderTime
CommonEnd
AppointmentStartWhole
AppointmentEndWhole
BusyStatus
会议所有者
任务的公司名称
使用“导出到 PST”选项来还原丢失的项目。
部署完 UDP 代理之后，无法删除旧版本的独立 Exchange Granular Restore 实用工具。
此问题在以下条件下发生：
如果在部署 UDP 代理之前或之后安装旧版本的独立 Exchange Granular Restore 实用工具，则无法删除 Exchange Granular Restore 实用工具。
系统中存在两个版本的 Exchange Granular Restore 实用工具。
所有快捷方式均指向旧版本的 Exchange Granular Restore 实用工具安装文件夹。
要纠正这些情况，请执行以下解决方法之一以帮助您解决此问题：
在部署 UDP 代理之前或之后，从控制面板中手动卸载 Exchange Granular Restore 实用工具。
如果您运行当前版本的 Exchange Granular Restore 实用工具，请确保旧版本的 Exchange Granular Restore 实用工具已关闭，否则旧版本会在执行当前版本时继续运行。
在卸载旧版本的独立 Exchange Granular Restore 实用工具之前，从安装文件夹 (%ProgramFiles%\Arcserve\Unified Data Protection\Engine\Exchange GRT) 打开新版本的 Exchange Granular Restore 实用工具。
将文件还原到其他位置（远程共享文件夹）失败，活动日志中的错误消息为“访问被拒绝”。
还原目标为远程共享文件夹（如 \\FileServer\ShareFolder\RestDest），并且备份目标为具有相同路径的远程共享文件夹（如 \\FileServer\ShareFolder\RestDest）时，将发生错误。
如果用于连接到根共享文件夹的用户帐户不在权限列表中，无论用于还原目标文件夹的帐户为何，还原作业都将失败。
添加为备份目标分配的用户帐户，以构建到根共享文件夹权限列表的连接，并确保用户帐户具有还原文件的适当权限。
将用户帐户添加到备份操作员组，并确保其具有覆盖安全限制的权限。				
升级操作系统后，从 Arcserve UDP 代理 (Windows) 恢复文件时，您可能需要重新输入加密密码或会话密码。
如果恢复点启用了加密，则无需输入从当前服务器备份的恢复点的密码。但是，如果升级 Windows 操作系统（例如，从 Windows 2008 升级到 Windows 2008 R2），Arcserve UDP 代理 (Windows) 用户界面的密码不会自动填充，您必须重新输入密码。
记录恢复点加密密码或会话密码，并保存在安全位置以备检索之需。				
无法在还原过程中打开 VMDK 文件。
在还原 VMware 虚拟计算机时，我遇到以下错误：
					您没有该文件的访问权限，有关详细信息，请参阅还原调试日志。如有必要，请联系 Arcserve 支持。				
您可以查看还原调试日志中的以下日志条目：
					[VDDKLOG] CnxAuthdConnect:Returning false because SSL verification requested and target authd does not support SSL				
					[VDDKLOG] CnxConnectAuthd:Returning false because CnxAuthdConnect failed				
					[VDDKLOG] Cnx_Connect:Returning false because CnxConnectAuthd failed				
					[VDDKLOG] Cnx_Connect:Error message:SSL required				
该错误的原因是在 VMware ESX 主机上禁用了 SSL 身份验证。要解决此错误，请执行以下方法之一：
					使用 vSphere Client				
登录到 VMware vCenter/ESX  服务器。
依次单击“配置”、“高级设置”、“配置”、“默认安全性”。 
打开 ESX 服务器设置。
启用以下选项：
config.defaults.security.host.ruissl
如果数据存储上有备份会话，则当您单击“恢复 Virtual Standby”时，虚拟备机作业不会启动。
系统会将相应节点备份到 RPS 数据存储，将其复制到另一个 RPS 数据存储，然后使用复制源创建虚拟备用计算机。计划部署之后，如果虚拟备机作业存在较早的会话，那么您可以直接恢复 Virtual Standby。但在您提交作业之后，虚拟备机作业将不会启动。
要解决该问题，请首先执行手动复制。右键单击该节点，然后单击“立即复制”。复制完成后，即可恢复虚拟备机作业。
当转换器正在使用 Arcserve UDP 5.0 版且监视器（代理）正在使用 Arcserve UDP 6.0 版时，无法运行虚拟备机作业。
虚拟备机作业失败，并出现以下错误：
无法获取磁盘签名（签名为空）
在 Arcserve UDP 6.0 版中，VMWare VDDK lib 从版本 5.5 升级到版本 6.0。在 VDDK v6 中，初始化 VDDK lib 需要一个名为指纹的新字段。从 VSB 转换器进行的调用基于 Arcserve UDP 版本 5.0（其中缺少指纹）。这会导致从转换器到监视器的调用失败
要解决此问题，请将转换器更新到 Arcserve UDP 6.0 版。
将源节点上的 Arcserve UDP RPS 或 Arcserve UDP 代理升级到 Arcserve UDP 6.0 后，Hyper-V 上的虚拟备机作业失败。但是，Hyper-V 服务器上的 Arcserve UDP 代理不会升级。
Arcserve UDP 代理 (Windows) 将备份到 Arcserve UDP RPS 数据存储，并且 RPS 将升级到 Arcserve UDP 6.0。此外，Arcserve UDP 代理 (Windows) 将备份到共享文件夹，并且代理将升级到 Arcserve UDP 6.0。Hyper-V 上的虚拟备机 VSB 作业失败，并显示以下错误：
找不到 {http://webservice.arcflash.com}IsVmFileExist 的分派方法。
找不到 {https://webservice.arcflash.com}IsVmFileExist 的分派方法。
将 Hyper-V 服务器上的 Arcserve UDP 代理升级到 Arcserve UDP 6.0。
开机时，磁盘以脱机状态启动。发生这种状况是因为，在 Windows 2008 或更高版本的操作系统中引入了 SAN 策略。操作系统保护多个服务器访问的共享磁盘。服务器首次检测到磁盘时，Windows 将磁盘置于脱机状态。磁盘置于联机状态后，磁盘将仍保持联机状态。
此行为的其他原因与打开包含“只读”卷的虚拟机有关。要改变这种情况，请将卷置于可写状态的磁盘之上。
应用程序不支持使用 VMware 链接模式导入 vCenter 服务器。要保护链接模式组中的所有 vCenter 服务器实例，请分别添加每个 vCenter 服务器实例。
源计算机的系统卷或启动卷位于动态磁盘上时，Virtual Standby 不支持将恢复点转换为 Hyper-V 格式。
Virtual Standby 不支持创建 Virtual Standby 任务，该任务可用于定义在 Windows 2008 R2 SP1 和 windows 2012 Hyper-V Server 系统上保护的虚拟机所用的动态 RAM 数量。
在使用当前快照执行 V2P 恢复时，可能会显示一条指示以下内容的消息：
无法获取恢复点信息。
使用最新的快照执行 V2P 恢复，且在将 Virtual Standby 任务重新部署到节点之后节点的转换作业未完成时，会出现此行为。
提交 Arcserve UDP 代理备份作业来捕获节点的当前状态。然后执行节点的裸机恢复。
关闭 Virtual Standby 虚拟机，然后提交 Virtual Standby 转换作业来为节点创建当前恢复点快照。
V2P 用户界面可能不显示最新的快照。从最新的快照完成 V2P 恢复之后执行 V2P 恢复时，会出现此行为。
请使用 Arcserve UDP 代理裸机恢复执行 V2P 恢复。
备份源计算机（已安装 Arcserve UDP 代理时）包含原生 4KB 扇区磁盘，且 Arcserve UDP 代理备份作业已备份 4KB 扇区磁盘上的卷时，转换 Arcserve UDP 代理备份会话的备用虚拟机无法检测到相应 4KB 扇区磁盘的分区和卷。源磁盘包含 4 KB 扇区，并且备用虚拟机支持 512B 扇面磁盘时，便会出现此问题。转换后，因扇区大小变化，备用虚拟机中的客户操作系统无法找到磁盘元数据。
					注意：此限制仅适用于在 Hyper-V 服务器上运行的 Virtual Standby 作业。
对于基于主机的虚拟机会话，如果网络适配器连接到 VM，稍后适配器断开，那么 Virtual Standby 中列出的网络适配器将比 VM 中的当前列表多。				
2TB 磁盘文件的转换失败，因为 VM 无法创建快照。
Arcserve UDP 代理 (Windows) 的磁盘为 2TB，版本低于 5.5 的 ESX/ESX (i) 服务器仅支持最大 2TB 的虚拟磁盘。不过，在转换期间，以下错误会发生：
在 vSphere Client 中：
“创建的虚拟机快照 VIRTUALMACHINE 文件 <未指定的文件名> 大于数据存储‘<未指定的数据存储>’支持的最大大小”。
“文件大于数据存储支持的最大大小”。
在 ESX/ESXi 4.x 的 hostd 日志文件中：
“快照来宾无效：文件对于文件系统过大。”
在 ESXi 5.0/5.1 的 hostd 日志文件中：
“无法执行快照操作:错误：(21) 文件对于数据存储过大。”
这是 VMware 限制。版本低于 5.5 的 VMware ESX/ESX (i) 服务器支持的最大大小是 2T-16 GB，相当于 2032 GB。
建议将 VMware ESX(i) Server 5.5 用作目标，以便对大磁盘执行转换。
有关详细信息，请参阅 VMware KB 文章 1012384。				

在 Arcserve UDP 控制台 UI 中更改虚拟备机监视器的密码并升级其节点后，使用该监视器服务器的计划部署可能会失败。
部署计划失败，并显示以下错误消息：“无法对节点“xxx”应用“备份设置”。（无法从 xxx 连接到监视器：xxx。用户凭据无效）。”
在计划中编辑虚拟备机任务，输入监视器的正确密码，然后保存计划。
VSS 快照相关问题
为 VMware VM 的无代理备份生成编录失败
由于 VM 客户操作系统内的 VMware 或 Microsoft 所引起的 VSS 快照问题，为 VMware VM 的无代理备份生成编录可能会失败，并显示以下消息： 
					“无法将索引块映射到正确的卷块上。发生 IndexAlloc 错误。”				
运行“chkdsk”以确保客户操作系统内的数据一致性。
关闭 VM，避免在客户操作系统内发生 VSS 快照。
在关机状态下备份 VM。
					注意：此问题很少发生。有关详细信息，请参阅 VMware KB 文章 2006849 或 Microsoft KB 文章 2853247。				
文件复制相关问题
文件复制/存档作业不会启动。
文件复制/存档作业不会启动。
在某些少见的情况下，需要为文件复制/存档作业保留用于指示恢复点的文件，并且在完成文件复制/存档作业后无法删除该文件。此类文件在特定节点的备份目标文件夹下命名为 *.alck，并且文件大小为零。作为变通，您可以找出这些文件并手动删除它们。
单个安装程序相关问题
当目标卷为 FAT32 文件系统时，从单个安装程序（使用 ASDownloader.exe）下载“Arcserve Backup”或“Arcserve High Availability”组件会失败，这是因为软件包会超过 FAT32 文件系统支持的 4 GB 文件大小限制。 
作为变通，您可以下载到 NTFS 卷。
设备升级相关问题
					将设备升级到 Arcserve UDP v6 后，无法在该设备上执行出厂重置				
在 Arcserve UDP 设备上升级到 Arcserve UDP v6 后，您将在 Arcserve UDP 控制台的“设置”选项卡中看到“出厂重置”。如果您尝试通过单击“执行出厂重置”来执行出厂重置，然后在“确认出厂重置”对话框中单击“重置”，则会显示以下错误消息︰ 
					设备出厂重置失败。通过在 cmd 中的路径 C:\Program Files\Arcserve\Unified Data Protection\Management\Appliance 下使用以下命令来手动重置设备出厂设置︰“powershell.exe .arcserve_factoryreset.ps1 –perserve_data –auto_reboot”。				
					注意：错误消息不正确。对于升级到 UDP v6 的设备用户，出厂重置不受支持，因为设备计算机上没有 Arcserve UDP 恢复分区。
										在设备上使用 Linux 备份服务器时，Linux 即时 VM 作业失败				
如果您在设备上使用 Linux 备份服务器，该设备上不支持 Linux 即时 VM 恢复点。
Linux 即时 VM 作业失败，并显示以下错误消息：
无法从 VM $vmname 获取 IP 地址。请验证该 VM 和备份服务器是否在同一网络中。
此故障是由在即时 VM 作业中创建的备用 VM 所致。它会尝试通过 Appliance_hostname:8014 连接到 Linux 备份服务器，尽管您已通过 Appliance_hostname:8018 将 Linux 备份服务器添加到控制台。由于设备计算机上的端口 8014 由 UDP Windows 代理服务监视，因此即时 VM 作业将失败。 
您可以使用一种变通方法通过静态 IP 来解决 Linux 即时 VM 作业的问题。
					请按照下列步骤操作：				
在 UDP 设备计算机上找到两个空闲端口，例如 8018 和 8035。
您可以使用“netstat -aon|findstr "port"”来验证相应端口是否已被占用。  				
					注意：如果您正在升级 Arcserve UDP v6，则 UDP 设备计算机上的端口 8018 已配置为重定向到 Linux 备份服务器的端口 8014。使用以下命令在 UDP 设备计算机上释放 8018︰
					netsh interface portproxy delete v4tov4 listenport=8018				
在 Linux 备份服务器上，在以下文件中将 port="8014" 修改为 port="8018"︰/opt/Arcserve/d2dserver/TOMCAT/conf/server.xml
在 Linux 备份服务器上，在以下文件中添加一个新行“dss_port=8035”︰/opt/Arcserve/d2dserver/configfiles/server.cfg
注意：如果文件不存在，请创建该文件。 运行以下命令重新启动 Linux 备份服务器：
					/opt/Arcserve/d2dserver/bin/d2dserver restart				
运行以下命令，以在 Linux 计算机的防火墙上允许端口 8018 和 8035 进行通讯︰
					#iptables -A INPUT -p tcp --dport 8018 -j ACCEPT				
					#iptables -A INPUT -p tcp --dport 8035 -j ACCEPT				
					#/etc/init.d/iptables save 				
在 UDP 设备上，使用命令行运行以下命令︰ 
					netsh interface portproxy add v4tov4 listenport=8018 connectaddress=192.168.10.2 connectport=8018 protocol=tcp				
					netsh interface portproxy add v4tov4 listenport=8035 connectaddress=192.168.10.2 connectport=8035 protocol=tcp				
在 UDP 设备计算机上
打开位于以下位置的 setdns.ps1 文件： 
					C:\Program Files\Arcserve\Unified Data Protection\Engine\BIN\Appliance				
在该文件的末尾添加以下两行︰
netsh interface portproxy add v4tov4 listenport=8018 connectaddress=$VMIp connectport=8018 protocol=tcp
netsh interface portproxy add v4tov4 listenport=8035 connectaddress=$VMIp connectport=8035 protocol=tcp
在 UDP 控制台上，使用端口 8018 更新 Linux 备份服务器。
					重要信息！此变通方法不适用于以下选项︰
Linux 迁移 BMR 作业
通过默认的 Linux 备份服务器为 Linux 即时 VM 作业设置 DHCP