Client version 1.4.8 but the same behavior was spotted on 1.4.6.
UrBackup just did a full file backup of “. . . .”.
Report:
( 2 infos, 1 warning, 3 errors )
2015-03-18 12:14:24(info): Starting full file backup…
2015-03-18 12:19:35(error): Cannot access directory to backup: “\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy51\Maintenance\ . . . . " Errorcode: 2 - The system cannot find the file specified.
2015-03-18 12:19:35(info):
2015-03-18 12:19:35(error): Constructing of filelist of " . . .” failed: error - index error
2015-03-18 12:19:35(error): Backup had errors. Deleting partial backup.
2015-03-18 12:19:35(warning): Exponential backoff: Waiting at least 1h 20m before next file backup
After this error appear there is no more backups from clients. We registered this error on different clients Win 2003 and Win 2008. urBackup client service restart do not help. After long investigation we found that there is need to remove backup directory and add it back - after this operation client start working correctly without restart.
I had this issue when I changed the name of a specific directory. I’m still looking where this change is kept. If I rename it back to its original (former) name, I have a successful backup.
Example:
Former directory name:
C:\Users\User\MyDrive
New directory name:
“C:\Users\User\My Drive” <- This fails unless I rename it to its original name.
Should be a shadow copy issue.
open command windows and type “vssadmin list writers” If you see any errors or vss services that have not completed you need to restart all VSS services. Next step is this does not work is to delete all shadowcopys and reboot.
Should be VSS, I would agree. But for all the writers, I have “Stable” and “No error.”
But I also noticed the SQLite DB, it had the old folder name in it as well. I changed it to the new one and it also fixed the issue.
So maybe this is just coincidence? No idea on my end. I do know that indexing only took 10-15 minutes this time around whereas overnight before never completed indexing. Made me wonder what it was actually doing.
You need to delete all the shadowcopys.
I think for server the command is “vssadmin delete shadows /all” in the command windows
I have this problem on one PC. Does anyone have an idea of what’s causing this? I deleted all VSS and restarted the PC and didn’t help. PC is running Win 7 x64 pro and the server is running 2.1.19 and is an internet setup. I have other PCs that are currently being backed up and don’t have problems.