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:
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.
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.
However, at some point the mechanism changed from
to relying on a global variable
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?