I just setup a new 2.4.12 server with 2.4.10 cbt clients and have an issues with an SBS 2011 server failing to index files. It tried index files 4 times overnight and failed with the following error.
Cannot access path to backup: “\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy228\wsus\susdb\updateservicesdbfiles” Errorcode: 123 - The filename, directory name, or volume label syntax is incorrect.
The WSUS SQL database service is stopped if it makes a difference.
(The default configuration backs up MSSQL automatically and that somehow fails)
Wow, thanks for such a quick response! I’ve made the change.
This wasn’t setup as a location to backup. Would be worthwhile to not fail indexing files and stop the entire backup based on an error with a location that’s not being backed up?
The path comes from MSSQL (via Windows Backup API). So I guess the thing to think about is if MSSQL should be backed up by default, since it seems to also be used with stuff that doesn’t need to be backed up sometimes.
In this case it’s a ~30GB WSUS database and is not needed. Maybe adding something in the initial wizard for what to backup would be good. I think it’s a good idea to backup by default, this is probably an edge case of a big SQL database that doesn’t need to be backed up.
What happens if this client has image backups selected or the database included in file backups. Do you get a copy of the database in the VHD and a separate copy from the Windows Backup API somewhere else? I have some ~500GB Exchange databases that would be a waste of bandwidth and space to have multiple copies accidentally.
Yeah, it gets backed up multiple times and, unless you have file system block dedup, saved multiple times. Exchange is a bit of a special case since one needs to manually enable circular logging if there is no backup program using the Windows API that backs it up. Otherwise it’ll keep the database logs forever.