Event ID: 57476

[John_Senter]

We just started using Backup Exec 10 on a Windows 2003 SP1 server. This server is a primary File-and-Print server and there are several PST files on the server. We are getting errors in the server applicaiton log with event id 57476, from BackupExec, stating:
"The operating system returned an unusual error while backing up the following file:

H:\Users\RS\NFOSTER\nfoster2.pst

It is possible that this file is incomplete and therefore should not be restored. "

Is there a way to keep BackupExec from putting these error messages in the application log? We did not get this on the Windows 2000 server running BackupExec 9.0.

Thanks

[padmaja_rajopad]

Hi,

Please run CHKDSK on the media server and try running the backup again.

Please refer to the following document

Event ID 57476: "The operating system returned an unusual error while backing up the following file. It is possible that this file is incomplete and therefore should not be restored." is reported in the Event Viewer when performing a backup.

http://support.veritas.com/docs/252175

Hope it helps.

NOTE : If we do not receive your reply within two business days, this post would be marked ‘assumed answered’ and would be moved to the ‘answered questions’ pool.

[John_Senter]

The file is not corrupt. The files are Outlook PST files which are open and had always displayed as "possible corrupt" in Backup Exec. Because of this we put in the reg fix to continue the backup on corrupt files. The issue no is why are all of these messages being placed in the Application log for the system. When we were running WIndows 2000 and BackupExec 9.0 this did not occur. Now that we are running Windows 2003 and BackupExec 10.0 we are. Is there a way to keep BackupExec from writing these events in the system Application log.

[Deepali_Badave]

Hello,

As you are getting an "Event ID: 57476", what error message does job log displays?

NOTE : If we do not receive your reply within two business days, this post would be marked assumed answered and would be moved to answered questions pool.

[John_Senter]

The job history shows:
WARNING: "F:\Users\CBT\JWANG3\Outlook Files\2005.pst" is a corrupt file.
This file cannot verify.

This has done this since 8.6 and we are OK with this since a PST is a open database type of file.

[Amruta_Purandar]

Hello,

Please recreate the job and verify the results.


NOTE : If we do not receive your reply within two business days, this post would be marked assumed answered and would be moved to answered questions pool.

[John_Senter]

I installed a another server last weekend with the same configuration and it too is putting errors like that in the application log.

The problem is not that the backup job shows possible corrupt files during the backup, but that it puts a entry in the application log; which it did not do on any of the Windows 2000 servers with Backup Exec 9.0.

[Amruta_Purandar]

Hello,

Please recreate the job on the original server and verify the results.
Update us on the same.

NOTE : If we do not receive your reply within two business days, this post would be marked assumed answered and would be moved to answered questions pool.

[John_Senter]

I deleted the job and recreated last night. Today I checked the applicaiton log and the error messages are still being generated.

[priya_khire]

Hello,

Are you using the Advanced open file option during backup? If not, use it and then check the results. Also check if the file is in use during the backup. Close it and then run the backup.

If the problem persists, revert with details to the above questions.

Note : If we do not receive your reply within two business days, this post would be marked ‘assumed answered’ and would be moved to ‘answered questions’ pool.

Regards.

[John_Senter]

First, I do not have Open File Agent and do not want to purchase it. Second, the file is open that is why the message comes up.

The point here is that I know the files are open and the job log in BackupExec will show it has possible corrupt. What I am tring to find out is if there is a way to keep BackupExec from placing these messages in the system Application log. It did not do this in version 9.0 with Windows 2000.

[Mike_Ziegenhard]

The theoretical maximum for the old, before Outlook 2003, PST-Files was about 2 GB. I read that it´s better to keep them around 600 MB. Try to split, if they are too big.

Regards

Mike Ziegenhardt

[John_Senter]

I guess I have not explained the issue correctly. There is nothing wrong with the PST files, they are not corrupt, they are open. BackupExec has reported them as corrupt since 8.5. To prevent the backup job from failing we added the registry key to prevent the job from failing on corrupt files. The job history still showed the files were corrupt. We are OK with this.

The issue is with BackupExec 10, it logs a entry in the Windows Application Log for every file it thinks is corrupt. We do not want this to happen. Is there a way to keep BackupExec from writing this entries in the system application log?

[rich_Minkowetz]

How do you the .pst is not corrupt? Microsoft provides a utility program to fix .pst files that have issues. The program is scanpst.exe.To locate the program perform a search for the filename, scanpst.exe, on the users PC. If errors are found, the scanpst program offers you the opportunity of creating a backup copy. I strongly recommend the creation of the backup. After the backup copy is created, the program will fix the .pst file.

In my experience at my site when .pst files are backed up by BE 10.0 the report will display the file(s) is 'skipped'. I have a detailed log created for every backup. It only takes up disk space. I am from the olde school when mainframe backups printed a substantial amount of paper. A lot can be gleaned from the detailed backup report.

[david_chaika_2]

John, I get the same thing. I have always gotten open file messages for open PST files, not just BE 10 and W2003. You have to learn to live with it, I'm afraid. I do remember though, that with some similar problem with another program there was some kind of fix you put in a TXT file somewhere that tells Event Log to not display errors of type 9999. Not very helpful, I know, and I have lost the reference. Second, there is some kind of reg edit to have BE skip open files. I do not use this because it would have to apply to all files identified as "corrupt", and I want to know when it really hits a corrupt one. HTH.
David Chaika

[John_Senter]

I do not want to skip the open files. I just want to see if there is a way to keep BackupExec from logging the corrupt files in the Windows Application log. With our BE 9.0 on Windows 2000 it did not do this, it only logged the corrupt files in the Backup Exec job log, which is fine.

[Matt_Western]

John have you ever worked out how to stop these errors being placed in the event log?

I am getting the same thing but don't think I'll bother trying to ask how fix it, it seems to hard to understand.

Can you let me know if you have please. Just reply to this post.

[mitch_sprague]

It looks like this was an issue a few years ago but I don't see a solution posted.  Has anyone come up with a resolution to this issue?  I have the same events appearing in the application log but I'm not convinced that a problem actually exists.  I've followed the suggestions noted hear and don't see any change in the behavior.  Can anyone provide an update on any progress towards a solution?  Do I need to actually concern myself with the events: is it a real problem or a false indicator?  Any update would be helpful.

Thanks

[Mani_S]

 David says correct.

I am also facing same issue. If somebody open their .pst file from backup location(Which location to be backup), the backup had cancelled and it shows .pst file was corrupted. Actually the the file was not corrupt,it had is open while take the backup.

Regards,

Mani.s 

[T_C_2]

ok .. here it is; I do not know whay no one suggested this yet.

Tools > Options > Configure Alert Categories

Select Job Failed and clear the check box next to Record event in the windows even log.

-- Need truth supporting BE again --

Tim