1

I am implementing a backup of Hyper V VMs using diskshadow based on Windows VSS (Volume Shadow Copy Service).

The implementation is pretty much as described in DiskShadow / Xcopy BACKUP of Hyper-V, where the diskshadow script is like the following:


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

In HyperVBackup.cmd the actual copying of the shadow copies to a backup drive is done using xcopy. This is oviously the most time consuming part of the backup process.

The begin backup and end backup commands send events to vss writers to allow them to prepare for shadow copy creation and to react on the end of the backup.

  • Is it a good idea to call end backup AFTER EXEC HyperVBackup.cmd? Wouldn't this force vss writers to stay in an intermediate state as long as the long xcopy part takes?
  • Wouldn't it be appropiate to call end backup BEFORE the line EXEC HyperVBackup.cmd?

Actually I do not know what vss writers typically do when they receive the event sent by end backup.

Thanks, nang.

Community
  • 1
  • 1
nang
  • 421
  • 6
  • 16

2 Answers2

2

as an alternative to diskshadow you might also want to check out the following open source Hyper-V backup solution supporting CSV and including a command line tool:

http://hypervbackup.codeplex.com/

Alessandro Pilotti - MVP
  • 21
  • 2
0

end backup basically signals all the vss writers that a successful backup has occurred. You probably don't want to do that until after all data has been successfully moved to a safe location. In your case, you will not want to signal a finished backup until the HyperVBackup.cmd script has finished without errors and likewise the xcopy has finished without errors.

The reason for this is that some writers, such as Exchange or SQL Server will flush transaction logs when they are signaled by end backup. You don't want the transaction logs flushed until after they have been successfully backuped up and in a safe location.

The begin backup shouldn't be holding anything in an intermediate state. It just tells the vss writers "hey if there is any maintenance that needs done close to a backup window, do it now". I don't know the specifics of vss writers, but I could also see begin backup being used to set a marker, so when end backup is signaled, it can say "data up to this point is good and you can now run amok with it." For example, you don't want to flush logs up to the time of the end backup command, rather the end backup command will flush logs up to the time of the begin backup command.

The only "intermediate state" that happens is during the file system freeze. The freeze happens during the create command and is automatically thawed at the completion of the create command.

James
  • 385
  • 3
  • 11