Missing backup path

When doing a file backup on Windows and you have more the one path setup for backup.
If one of the paths isn’t accessible at backup the whole backup job fails?
Shouldn’t we be able to take backups on the the paths that are still there?

To replicate set one path to a USB device, run one backup and then remove the USB.
Run the backup again and the job fails all paths since it can’t find one.
There makes no diffrens where in the chain the path is (eg. first, middle, last)
Seen it on client version 2.0.9 and 2.0.11

Here’s what the server says, this is on a machine with a USB disk.
It’s from one of my external users. I can replicate it on an internal machine if you want more logs or if you want me to test something.

Under Filebackups add the following as path:


Would this be something you would also do if you had a clustered virtual machine that hopped between two physical machines, and you were backing up the same path to the virtual on both physical machines?

@tarakesh I’ll try it out.
But I still think it would be better that the backup ran on the paths that works.
Now I need to specify backup paths in 2 places plus I have to break the settings coming form the server since I change them locally on the client.
And also most of my users don’t know how to type a path or what it is, the browse button is complicated enough :wink:

The issue is the same with Windows client v2.0.32
I just had a client repeatedly failing. When I looked into it one of the backup paths no longer existed (it was an external drive).
See below;
12/09/16 16:08
Cannot get volume for path “D:\Client Data\Pat Pritchard”. The system cannot find the file specified. (code: 2)
12/09/16 16:08
Creating snapshot of “Pat Pritchard” failed.
12/09/16 16:08
Error getting volume path for D:\Client Data\Pat Pritchard
12/09/16 16:08
Scanning for changed hard links on volume of “Pat Pritchard”…
12/09/16 16:08
Error getting volume path for D:\Client Data\Pat Pritchard
12/09/16 16:08
Cannot access path to backup: “D:\Client Data\Pat Pritchard” Errorcode: 3 - The system cannot find the path specified.
12/09/16 16:08
Constructing of filelist of “PatPritchardLaptop” failed: error - index error
12/09/16 16:08
Backup had an early error. Deleting partial backup.

I would prefer it to omit the missing path from it’s file list and continue with a warning. At least that way everything else is safely backed up while I correct the backup paths.


I have a couple of others failing in a similar manner. At least I know where to look now.

You could either add an exclusion rule for that path (not advised) run remove_unknown.bat and see if that fixes your issue, or do what tarakesh advised: [quote=“tarakesh, post:2, topic:2000”]

Restart the services on both machines (server and client) or just restart them in general. Make sure the server is at or above the client version, and if all else fails check your permissions (technically you should check these first.)

I’d rather not create exclusion rules for every path on every client.
I have one user that is always shifting folders about without thinking about his backup paths.
It would just be helpful if the backup continued without the missing path but a warning was generated.


I already have “Do not fail backups in case of hash mismatches or read errors” ticked.
It’s not applicable as the error is during the indexing stage and not a read error.
As I said earlier, adding optional to each and every path is not an option (pun intended)

Thanks anyway

You don’t have to add it to every path. Let’s say it was just D:\Client Data\Pat Pritchard.

If they somehow never moved their files from that path, all you would have to do is add in D:\Client Data\Pat Pritchard|Pat Pritchard/optional

Or, if it was constantly moved around in Client Data, then just make it D:\Client Data|Client Data/optional

I do agree that making every path optional is just horrible within itself, but just trying to give you options to make it work.

Alternatively, you could just smack the person hard enough until they stop moving their files around, or make them a static folder that they couldn’t move – tell him that only stuff in this folder is being backed up, and anything and everything that is not in that folder will not be backed up.

Whatever you stick with, I hope it goes well for you @hippy1970.

I like the static folder idea but it shouldn’t be necessary for responsible users, who normally don’t deserve a smack about the head.
Admittedly it shouldn’t happen often but this is the real world and it would be good to have the option to raise a warning flag while still backing up everything else.

Thanks for the input :wink:

Just thinking about the “Do not fail backups in case of hash mismatches or read errors”.
Presumably the intention is to continue if a read error occurs during the actual reading of files. Which may occur if the drive is failing or corrupt for any other reason.

This means that at least the intact files are backed up before the drive goes down.

What would happen if, due to disk issues, a folder is corrupt? Would the indexing fail and so the entire backup?

I see hash mismatches and read errors when a file gets changed or disappears while the backup is running. It seems there is a hashing/indexing portion and then a backing up portion and when things change in between that time, the backup fails.

If people keep moving their data around, I’d suggest just backing up everything and just specifying the root folders (with optional).

I’m currently running into this issue. If a path slated to be backed up does not exist, then the backup should NOT completely fail. It should flag an error and continue to back up the other paths that still exist.

I’m talking specifically about paths selected at the client PC via right click on the taskbar icon and “Add/Remove backup paths”. By default, we back up all clients’ D:\ partitions, but sometimes there are a few folders on other partitions that the client wants to back up. These folders are unique to every client/user and it is not practical to add anything at the server, therefore it is done at each client machine.

The problem happens when at some point in the future the user deletes or renames one of those folders and doesn’t remember to change the UrBackup client. Then the backup starts completely failing and nothing gets backed up!

And nobody knows about the error until someone manually looks at the server log. (We have the server set up to send e-mails; the test e-mails are successful, but we have yet to receive an e-mail when an error occurs).

Sorry to keep on bringing this up but I have another client that keeps failing to backup.
Everything was fine but now this;
‘Errors 13/11/16 12:12
Cannot access path to backup: “\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy10\Users\Sam\Documents\Vehicles” Errorcode: 2 - The system cannot find the file specified.
13/11/16 12:12
Constructing of filelist of “SamCarroll” failed: error - index error
13/11/16 12:12
Backup had an early error. Deleting partial backup.’

I have emailed the client. I suspect he has deleted the Vehicles folder but it’s still in the paths for backup.
Can we please have the client log a warning but continue if a backup path is missing?
Otherwise this is going to continue and, if gone unnoticed, could be disastrous.


I would need someone who knows more about this to verify, but could 8dot3 names be causing this issue?

I back up a file server that constantly has people deleting, adding, and editing files, and after turning off 8dot3 DOS names I have never had a problem since.

As far as I know, it’s a simple on/off switch for 8dot3 names; but I don’t know if C: will allow you turn off 8dot3.

fsutil 8dot3name set F: 1 (disable on selected volume)


fsutil 8dot3name set 1 (disable all)

May not be useful for the original question, but it might be for your most recent one @hippy1970 .