我正在使用基于Windows VSS(卷影复制服务)的diskshadow实现Hyper V虚拟机的备份。
其实现与Hyper-V的DiskShadow/Xcopy BACKUP中描述的非常相似，其中DiskShadow脚本如下所示:
<>以前
set context persistent
set metadata C:backup.cab
set verbose on
begin backup
add volume C: alias ConfigVolume
#The GUID of the Hyper-V Writer
writer verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
create
EXPOSE %ConfigVolume% Y:
EXEC HyperVBackup.cmd
UNEXPOSE Y:
end backup
之前在HyperVBackup 。CMD命令，使用xcopy将影子副本实际复制到备份驱动器。这显然是备份过程中最耗时的部分。
begin backup和end backup命令发送事件给vss写入器，允许他们为创建影子副本做准备，并在备份结束时做出反应。
- 在
EXEC HyperVBackup.cmd之后调用end backup是一个好主意吗?这会不会迫使vss写入器保持在中间状态，就像长xcopy部分所花费的时间一样? - 在
EXEC HyperVBackup.cmd行之前调用end backup不合适吗?
实际上我不知道vss编写器在收到end backup发送的事件时通常会做什么。
谢谢,nang .
作为diskshadow的替代方案，您可能还想查看以下支持CSV并包含命令行工具的开源Hyper-V备份解决方案:
http://hypervbackup.codeplex.com/end backup基本上向所有vss写入器发出了备份成功的信号。在所有数据都成功移动到安全位置之前，您可能不想这样做。在您的情况下，您不会想要在HyperVBackup完成之前发出备份完成的信号。CMD脚本已经完成，没有错误，同样的xcopy已经完成，没有错误。
这样做的原因是一些写入器，如Exchange或SQL Server将在end backup发出信号时刷新事务日志。在成功备份事务日志并将其保存到安全位置之前，您不希望刷新事务日志。
begin backup不应该持有任何处于中间状态的东西。它只是告诉vss编写者"嘿，如果需要在备份窗口附近进行任何维护，现在就去做"。我不知道vss编写器的具体细节，但我也可以看到begin backup被用来设置标记，所以当end backup发出信号时，它会说"到目前为止的数据是好的，现在可以使用它了。"例如，您不希望刷新到end backup命令的时间，而end backup命令将刷新到begin backup命令的时间。
唯一发生的"中间状态"是在文件系统冻结期间。该冻结发生在create命令期间，并在create命令完成时自动解冻。