我正在使用 BackupExec 和 VCB 来备份一些虚拟机。据我了解，作业前脚本创建了我的虚拟机的快照，将它们作为虚拟目录安装在我的备份服务器上，然后我的备份执行作业就像正常一样备份本地文件夹。我遇到的问题是在作业前脚本期间发生的，并且从未安装过一台特定服务器的目录。
当我查看 VI 客户端并查看最近的活动时，我看到快照已开始但尚未完成。它似乎在 15 分钟后超时，因此永远不会备份服务器。
我以这种方式备份了多个虚拟机，其他虚拟机工作正常。麻烦的虚拟机有一个 85GB 的虚拟磁盘，然而，另一个可以工作的虚拟机有一个近 100GB 的虚拟磁盘。
我想知道VM还有什么可能导致快照需要很长时间才能创建。这可能是VM主机的问题吗？VM 主机是一个非常强大的服务器，没有一个 VM 来宾被大量使用，而且备份是在非工作时间运行的，因此服务器不应该只是过度工作。是否有任何日志或工具可以用来查看是什么减慢了快照速度？
VMWare 使用术语快照相当松散。它实际上并没有创建服务器的副本，它所做的是停止对现有磁盘文件进行任何更改 - 并将更改重定向到快照生命周期内的增量文件。
这意味着：
我认为VCB进程所做的就是做一个快照（这样数据在复制过程中不会改变），然后对冻结的文件进行克隆以进行备份。这可能需要一些时间 - 尽管您提到它在更大的服务器上成功，所以这可能不是问题。
一种可能性是您是否有任何虚拟磁盘被标记为独立的。如果是这样，这些将被快照进程忽略，也可能被 VCB 忽略。不确定 VCB 如何安装驱动器，但也许它需要一个标记为独立的驱动器？
已经提到了延迟和 SCSI 预留，而这些通常是原因。
其他要检查的事项：
您在这个特定 VM 中的 vmtools 是否安装并正常运行？虚拟机是否运行过时版本的 vmtools？VMware 工具是获得良好快照的关键。例如，更新版本的 ESX 3.5 和 vmware 工具支持使用 VSS 作为 Windows VM 的快照提供程序，但更新版本的 vmware 工具需要安装 VSS 支持并且需要进行配置。
备份资源：这个特定的作业是否需要长时间排队？如果磁盘阶段或磁带驱动器正在使用中并且作业在快照阶段停留很长时间，则快照可能永远不会真正被拍摄。鉴于您的描述，这似乎不太可能，但总的来说可能需要检查。
发生这种情况时检查您的 san 上的延迟。可能是另一个 vm 或进程（sql server 作业？）同时击中了 san。
您在同一个 LUN 上托管了多少台虚拟机？他们有多忙？
我们在这里遇到了很大的麻烦，一些 VMware ESX 服务器在一个 LUN 上放置了如此多的 SCSI 预留，其他使用相同 LUN 的 ESX 服务器无法再写入 LUN。不过，您应该能够在日志文件中看到这一点。
ESX 在执行元数据更新时会在整个 LUN 上设置 SCSI 预留。VCB 可能会在此处对 LUN 上已经很重的负载增加一些。
官方说，这个问题已经修复了几个月，但我们还是时不时遇到麻烦。
另一件事，确保在有针对 VM 的快照时，碎片整理永远不会运行。增量文件只是在大小上爆炸。