Backup failing - "Shadow copy was probably deleted while indexing."

After many months of error-free backup, I’m now seeing the dreaded ‘Shadow copy was probably deleted while indexing.’

The server is on a Windows 10 machine, and the client is also on a Windows 10 machine.

Here’s the relevant section of the backup log:

03/04/20 13:36 ERROR Error while getting files in folder “\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2786\Users*****
\AppData\Local\Google\Chrome\User Data\Default\Extensions\ghbmnnjooekpmoecnnnilnnbdlolhkhi\1.9_0_locales\no”.
Windows errorcode: 3. Access to root directory is gone too. Shadow copy was probably deleted while indexing.
03/04/20 13:36 ERROR backupcom->DeleteSnapshots(dir->ref->ssetid, BJECT_SNAPSHOT_SET, TRUE, &dels, &ndels) failed . VSS error code VSS_E_OBJECT_NOT_FOUND
03/04/20 13:36 ERROR Deleting shadowcopy failed.

I realize that there is a FAQ entry for this sort of problem, but it appears to be a little out of date. In particular, the System Protection panel does not mention VSS, but sort of implies that the amount of disk page you are reserving is for restore points. I wonder if space for VSS is still configurable.

However, disk space doesn’t appear to be a problem. The client disk size is 912 GB, of which 249 GB are used. 10% (90 GB) is reserved for system protection.

I would love to have any suggestions about how to trouble-shoot this issue.

If you want to investigate this look into the Windows Event Log (Event viewer -> application events) and look for errors with “VSS” as source.

If this is a one time (or rare) thing, I’d just ignore it. UrBackup starts a follow up file backup pretty quickly and re-uses/resumes the partial previous backup. It’s more problematic with image backups as there it currently can’t resume/use the failed backup.

Hello, Martin-
Thanks for your suggestions. Unfortunately this problem occurs with every backup attempt, most recently during the “indexing files” stage. No files were backed up that time.

Here’s the error log:

3/04/20 20:04 Error while getting files in folder “\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2853\Users\Linda\AppData\Local\Google\Chrome\User Data\Subresource Filter”. Windows errorcode: 2. Access to root directory is gone too. Shadow copy was probably deleted while indexing.
03/04/20 20:04 backupcom->DeleteSnapshots(dir->ref->ssetid, VSS_OBJECT_SNAPSHOT_SET, TRUE, &dels, &ndels) failed .VSS error code VSS_E_OBJECT_NOT_FOUND
03/04/20 20:04 Deleting shadowcopy failed.
03/04/20 20:04 Indexing files failed, because of error

I checked for errors in the event log with VSS as the source and there are none. There are lots of info entries from VSS “shutting down for idle timeout” but I presume those are uninteresting. In fact there are no error-level events logged at all around the time this most recent backup failed.

Is it possible that the 10% of the system disk reserved for system protection (90 GB) is inadequate?

— Peter

I think I’ve found the problem here. It seems to have been a conflict between two backup programs.

In addition to UrBackup, I had been running Carbonite on the client computer. Carbonite was for off-site backups, UrBackup for local backups.

According to the Carbonite docs, it uses VSS, as does UrBackup of course. After I stopped the Carbonite backups, UrBackup has run properly for several days now.

I can only assume that the two programs were interfering with each other, perhaps in their use of VSS. I’m going to re-enable Carbonite now, but will set up backup windows so that the two programs aren’t ever running at the same time.