Windows VSS snapshot timeout increase (after reversion)

[solaris17]

Hello,

I have a 30TB SAN connected via iSCSI that runs and contains multiple VMs in my homelab. I wanted some of these backed up. Everything was working ok for a few months before making some large additions to connected VHDs. At this point my backups started to fail.

After looking into the VSS timeout issue I came across the following post from 2017 where another user had the issue. Following this response:

Shadow copy creation failed: DoSnapshotSet didn't finish properly

The timeout for the DoSnapshotSet operation is 180 seconds (in duplicacy_shadowcopy_windows.go):

	if !async.Wait(180) {
		LOG_ERROR("VSS_SNAPSHOT", "Shadow copy creation failed: DoSnapshotSet didn't finish properly")
		return top
	}
	async.Release()

You can modify this timeout if you know how to build from the source. It was increased to 180 seconds in 2.0.10 from 60 seconds in 2.0.9 and that is why 2.0.10 works better.

It appeared that the timeout was increased from 60 to 180sec (3min). This didn’t necessarily coincide with my logs so I continued researching where in the same thread came across a post regarding compiling it yourself.

Build Duplicacy from source

Duplicacy is written in Go. If you have Go installed you can run the following command to build from the latest source: go get -u github.com/gilbertchen/duplicacy/... The executable named duplicacy will then be created under $GOPATH/bin. You can also build the executable manually after running the go get command. cd $GOPATH/src/github.com/gilbertchen/duplicacy go build duplicacy/duplicacy_main.go The executable will be created under $GOPATH/src/github.com/gilbertchen/duplicacy with the n…

Following the guide (windows) I simply downloaded the source opened notepad++ modified the timeout to 10min (600sec) for the sake of testing, and recompiled.

This worked! the initial shadow copy stage finished in a little over 4min (240sec). However this enlightened me.

240sec is more than the 180sec initial vss timeout bump stated in the 2017 thread. However, moreso when I was manually recompiling the source code pulled down from git, had the timeout set to 60sec. Less than half of the vss bump committed in 2017 and was as far as I could find the original timeout.

I then went to the repo and dug into this. It appears that the modification did infact take place.

Increase VSS operation timeouts

However, at some point the mechanism changed from

if !async.Wait(20)

to relying on a global variable

if timeoutInSeconds

It seems to me that when this modification happened the timeout was regressed back to 60 instead of carrying over the initial 180sec modification. With that said; with backups of large data on loaded machines sometimes going over this would a subsequent modification increasing the timeout to 5 or 10min be harmful?

[gchen]

The backup command has a -vss-timeout option:

   -vss-timeout <timeout>       the timeout in seconds to wait for the Volume Shadow Copy operation to complete

[solaris17]

I see thank you. I generally use the GUI even if it may be dumbed down. I was just under the impression the defaults were set higher.

[gchen]

For the native GUI version, you can create a registry value ShadowCopyTimeout under HKLU\Software\Duplicacy\Job<n>. It must be a string value that indicates the number of seconds to wait. This value will be passed to the CLI so if you set it correctly you’ll see the -vss-timeout option in the log.