I am not entirely sure what all to say about this - we have a file server that we backup almost daily, but these past few times it has been hanging up on one file.
This is the log:
Info | 07/22/16 | 16:31 | Starting incremental file backup…
Info | 07/22/16 | 16:33 | Scanning for charged hard links on volume of “H”…
Info | 07/22/16 | 16:33 | Indexing of “H” done. 284 filesystem lookups 170574 db lookups and 223 db updates
Info | 07/22/16 | 16:33 | SERVER: Loading file list…
Info | 07/22/16 | 16:34 | SERVER: Calculating file tree differences…
Info | 07/22/16 | 16:34 | SERVER: Calculating tree difference size…
Info | 07/22/16 | 16:34 | SERVER: Linking unchanged and loading new files…
Warnings | 07/25/16 | 11:53 | HT: Error creating hardlink from “F:\urbackup\SERVER\160719-1011\H\dir\WORD FILE.doc” to “F:\urbackup\SERVER\160722-1631\H\dir\WORD FILE.doc”
Warnings | 07/25/16 | 11:53 | HT: Error creating hardlink from “F:\urbackup\SERVER\160719-1011\H\dir\WORDFILE~1.DOC” to “F:\urbackup\SERVER\160722-1631\H\dir\WORDFILE~1.DOC”
Errors | 07/25/16 | 11:53 | Writing metadata to F:\urbackup\SERVER\160722-1631\.hashes\H\dir\WORDFILE~1.DOC failed
Info | 07/25/16 | 21:38 | Waiting for file transfers…
Info | 07/25/16 | 21:39 | Waiting for file hashing and copying threads…
Info | 07/25/16 | 21:41 | Writing new file list…
Errors | 07/25/16 | 21:41 | Fatal error during backup. Backup not completed
Info | 07/25/16 | 21:41 | Transferred 2.52755 TB - Average speed: 80.1193 MBit/s
Errors | 07/25/16 | 21:41 | FATAL: Backup failed because of disk problems (see previous messages)
Info | 07/25/16 | 21:41 | Time taken for backing up client SERVER: 3 days 5h 10m 33s
Errors | 07/25/16 | 21:41 | Backup failed
Should I just delete the file; I saw there was a “Do not fail backup incase of has mismatch or read errors” but everytime I turn it on and save it the setting does not save to the client.
This, so far, is the only client that has this issue - I am backing up 6 Clients to this server.
The Server is Windows 2012 R2, and the client that is giving me trouble is Windows 2003 - however, I have two other Windows 2003 servers that backup files just fine, and the trouble maker is making image backups just fine.
Could you have a look if there are more details in the server log file at
C:\Program Files\UrBackupServer\urbackup.log ?
Two things stood out when browsing it in Notepad++:
2016-07-21 20:48:59: WARNING: File “\?\F:\urbackup\SERVER\160719-1011\.hashes\H\dir\WORDFILE~1.DOC” has wrong size. Should=60 is=193. Error writing metadata to file. -1
2016-07-22 09:40:37: WARNING: File “\?\F:\urbackup\SERVER\160719-1011\.hashes\H\dir\WRITING ANALYSIS.doc” has wrong size. Should=-8566065875623064602 is=193. Error writing metadata to file. -3
Never showed up in the logs on the interface about
I’m at a loss here on what to do; whether I need a way to “fix” those files or just remove them.
Is there a way to straight up get rid of hashes - aren’t they for internet clients or are they needed for local backups as well?
Couldn’t I just remove that
.hashes folder if I am going to do a full backup again?
Should note that
Writing Analysis.doc didn’t show up in the most recent failure - only the
WORDFILE~1.DOC, then the filelist constructing failed.
Also, I told you wrong because I normally forget that we have it set up this way.
UrBackup Client is on the Windows 2003 machine, but the files we are backing up are a network mapped drive to a SANS unit; however, it still stands that it only recently stopped working.
Can you put it into debug log mode and upload the debug log file/send me that?
If you don’t mind waiting until about August 1st.
I just enabled extensive logging following the wiki: https://urbackup.atlassian.net/wiki/display/UC/Enable+extensive+debug+logging
I’ll set it up to do the full file backup - the one it keeps failing on - and will send you the debug log files once it is “completed.”
This is for the client, not the server – see URL and wiki page location, also the full file backup might stop the issue from appearing again.
Do you have a server version that will make it quicker, because clicking on the link “enable extensive debug logging” in your UrBackup Server puts me back onto that client page. (https://urbackup.atlassian.net/wiki/#space-menu-link-content)
Also, there is a high chance that the issue will persist considering this is either the 2nd or 3rd time I have tried to complete a full file backup on this client.
However, I could just set up and incremental for the time being – that way there is not as much of a time restraint.
Alright, I will enable debugging on both the server and client. Perform an incremental file backup to save time, and after I get those logs and send them your way I will try another full file backup.
Incremental looks like it will take as long as the full at this point, so I’m expecting to send in the first set of logs - the ones from the incremental backup - on the 1st, then have to wait until at least the 4th for the full file backup log.
ttrammell sent me some more info and the issue is probably caused by 8.3 names (DOS names). One course of action would be to mangle all 8.3 names on the server, the other to advise people to turn off 8.3 name generation.
Let’s go with the second first: See here for how to do this: https://support.microsoft.com/en-us/kb/121007 . It has performance benefits as well.
I’ll add that link to the manual as setup step. The problematic pair of file names also should be rare such that it is improbable that many other people have this kind of problem, if they have not turned off 8.3 names.