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.
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
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).
Cannot get volume for path “D:\Client Data\Pat Pritchard”. The system cannot find the file specified. (code: 2)
Creating snapshot of “Pat Pritchard” failed.
Error getting volume path for D:\Client Data\Pat Pritchard
Scanning for changed hard links on volume of “Pat Pritchard”…
Error getting volume path for D:\Client Data\Pat Pritchard
Cannot access path to backup: “D:\Client Data\Pat Pritchard” Errorcode: 3 - The system cannot find the path specified.
Constructing of filelist of “PatPritchardLaptop” failed: error - index error
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)
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.
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.
Constructing of filelist of “SamCarroll” failed: error - index error
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.