I have a problem that has just started occuring on an F&P server that uses Backup Exec ver 10d to backup to LTO3 drives in that the backup sems to randomly report files as being corrupt, and hence does not back them up. The following nights backup may then back them up with out a problem but a different set of files will show as corrupt. Of those we've tested, none of the files actually have any problem being opened in their respective applications.
If you try to restore any of the files, you can select it from the restore tree and set the restore job running, but the job finishes saying it is 100% complete and successful having restore zero files.
The log file error message is:
"<path+filename> is a corrupt file. This file cannot verify"
I've looked through the symantec website and it seems to suggest it could be due to Aplications or users holding files open while the backup is trying to run, and to install AOFO to get arround the issue. But... firstly AOFO is not a free option, secondly, this is only happening on one server out of dozens of servers used for similar purpose, and finally where this is effecting a users home drive area there may be a hundred or so files in the same user area listed as corrupt and it's hard to conceive that this user would leave his PC on overnight with 100 files open.
NB these corrupt files could be any file - it's not limited to any particular file type
Thus far, this is the only post I've been able to find with a problem similar to mine.
This just began after I migrated our BackupExec server to VMWare ESXi. We were using a SCSI card which wasn't on ESXi's HCL, so I replaced it with one which is, but received the same results.
Like GreedyGreen, it matters not where the job fails, as all files can be successfully opened with no problem, and the failure is random each time. Regardless of whether we verify or not, the job fails, though it hasn't made it to verification since this occurred.
Also, we already currently use the AOFO option, so before you spend additional money, GreedyGreen, know that this won't necessarily resolve your problem.
One interesting point, though, is that the failure always seems to occur when it gets to our Archives volume, where all files are Read-Only.
- GreedyGreen, do you have Read-Only files failing as well?
- Dev, any ideas?
Many thanks in advance for any assistance with this one.