The support forum

Retry on ShadowCopy Fail

justbackmeup :

Oct 12, 2017

So I have a situation where sometimes a file is temporarily in use when Bvckup is trying to copy it, and ShadowCopy also fails.

2017.10.11 01:00:54.440 (UTC-5) 2 3             File is in use and cannot be accessed directly
...
2017.10.11 01:00:56.973 (UTC-5) 0 3             IVssBackupComponents::AddToSnapshotSet() failed with 8004230f
2017.10.11 01:00:56.997 (UTC-5) 0 3             Shadow copying is NOT available, file was NOT copied


In this particular case I know that the file will be available shortly (ie, less than a minute). What do you think about a setting (per-profile) to set an amount of time to wait to retry the copy action if the file is in use and ShadowCopy fails (if the profile was configured to try to use ShadowCopy), and perhaps also be able to set the number of times to retry (with waiting the same amount between retries)?

Alex Pankratov :

Oct 12, 2017



It sounds like you can either switch off shadow copying altogether or exclude this sort of temporary files from the backup.

While general purpose retrying mechanism may have its uses, I think that in this particular case it'd be the wrong thing to do. 8004230f stands for "unexpected provider error" and it typically means that there's something fundamentally off with your shadow copying service setup. Retrying on this condition is akin sweeping a problem under the carpet.

justbackmeup :

Oct 12, 2017

It's actually not a temporary file -- it's my Outlook PST. When Outlook is closed the PST gets accessed periodically by CompanionLink (www.companionlink.com), the software I use to sync my Outlook data with my Android devices.

I also have CrashPlan and ShadowProtect running, both of which back up this file (among others) and utilize ShadowCopy. So perhaps there is a collision happening occasionally with one of those? I know that ShadowProtect will sometimes throw an error regarding ShadowCopy failing, eg:

05-Oct-2017 16:00:13 service 302 Cannot take snapshot. Error: VSS provider not started. Method:  VSS API by STC provider. Volumes count: 3.
05-Oct-2017 16:00:13 service 301 try snapshot without writers
05-Oct-2017 16:00:13 service 302 Cannot take snapshot. Error: VSS provider not started. Method:  VSS API by STC provider. Volumes count: 3.
05-Oct-2017 16:00:13 service 199 try snapshot by  VSNAP API directly
05-Oct-2017 16:00:23 service 302 Cannot take snapshot. Error: The semaphore timeout period has expired. 0x80070079(2147942521). Method:  VSNAP API directly. Volumes count: 3.
05-Oct-2017 16:00:23 service 301 Cannot take snapshot (The semaphore timeout period has expired. 0x80070079(2147942521)) - retry in 30 seconds


It's not a huge issue at this point as it isn't happening often (the PST failing to get backed up). I suppose I could even just add another backup job to specifically backup that file more frequently (so that even if there's failures, it'll get backed up eventually). Although, am I going to run into issues if I have multiple Bvckup jobs backing up the same file (but presumably at different times) and using delta copy?

Alex Pankratov :

Oct 15, 2017

am I going to run into issues if I have multiple Bvckup jobs backing up the same file (but presumably at different times) and using delta copy?


You will have one job effectively voiding the delta state of all other jobs. So you are looking at full re-copying of the file when it gets backed up by a job other than the one that backed it up last time.

justbackmeup :

Oct 15, 2017

You will have one job effectively voiding the delta state of all other jobs. So you are looking at full re-copying of the file when it gets backed up by a job other than the one that backed it up last time.

That makes sense -- I was suspecting it would be something like that. Thanks for confirming.

New topic

Create
Made by Pipemetrics in Switzerland
Support


Follow
Twitter
Dev blog
Miscellanea Press resources
Testimonials
On robocopy
Company
Imprint

Legal Terms
Privacy