I have a bias toward what I think is relevant or not, but I'll try to be thourough with my information.
Backup Server: Windows 2003 w/BrightStor ARCServe Backup version 11.5 sp2 (newest)
Remote System: Windows 2000 server with a SCSI disk array and many logical volumes.
Explanation: The backup server handles about 35 server backups. We have a 2000 Exchange cluster, many Windows 2003 boxes of various varieties, and a few Unix boxes........all using proper 'agents' from BrightStor. Over the course of 4 months we've gotten all software and agents up to date, got all the servers using open file agents and tackled all those 'backup job' errrors that have lingered for years:
ACCEPT ONE! - The server mentioned above is called, well call it "remote" is a Windows 2000 server as I mentioned, running Windows and Open File agents. We have other 2000 servers also being backed up without error. I think the "remote" box is a 'Dell PowerVault 775N?' and is attached to a SCSI disk array. Logical volumes are like F:, G:, H:, I:, h:, O:, P:, - you get the idea - about 12 or so.
Problem: Over the years, and through different versions of agents.......certain volumes have "fallen out of favor" with the BrightStor software and the technician set up an "XCOPY" routine to move those volumes to another server to take the place of the normal tape backup job. Also those volumes were removed from the job itself. I'll explain why.
"remote" is our data server for the entire company. During the backup, or the night after in pasts years the technician would get a call that nobody could access data and 'remote' server was locked up. Meaning.......no screen.......no nothing.......and only a power down would fix it. Whatever volume (H:, O:, Y:, etc) was in the log file on the backup server when the thing locked was removed from the backup job and the job completed the next night. For example, over the years (N:, O:, Q:, U:, Y:) have been removed from the backup job and are being backup up using an XCOPY cmd file that runs daily. Of course, this is also means it is not on our normal tapes and is a poor setup.
Previous theories: Previous technicians have assumed it was a problem with MAC files due to complex, unorthodox naming conventions and another explanation I don't understand regarding a "short name" the MAC files have attached. Anyway, that was the only "common" factor the tech could find was that those volumes had MAC files on them.
**** I was the first one to contact CA tech support this week. They claim "no unusual file naming conventions or issues with MAC files exist that would cause the backup of any volume to crash the remote server". This week another volume (I:) went south on us, and started killing the backup. Sure enough, once I removed the volume (I:) from the backup job, the job worked fine.
C.A. said it cannot be file names or MAC related and gave a few ideas:
1) Try running without the Open File Agent - **Did this but I: volume still locked 'remote' server and caused reboot.
2) Try running without Symantec services running on backup server & remote server. - ** Same effect, 'remote' still crashed.
Neither of these make sense to me, because why would a 'service' be the issue? ALL the other volumes are backed up successfully on the same server and this particular volume is a good example of one that just suddenly stopped working.
I did turn ON detail logging on the test jobs for I: and found it stopped at a folder that contains an 'image' (Norton ghost) file, but CA claims there are no issues with ANY file types.
ANY experience with this?? Any ideas??
TIA - DH