backup issue

To all,
As always, I appreciate your help.
In an active/active cluster environment, I have a 68GB
database. Creates a 63GB .BAK file to a separate drive at
night that is on one of the physical nodes of the cluster,
but the physical drive is not assigned to the cluster.
The .BAK is only thing on the drive.
After performing chkdsk maintenance, I got deleting
indexing entry...MFT file. (I think this may be related to
Microsoft's KB327009)
So I've rebooted a couple times performing chkdsk /f and
the disk comes back clean. I backup the db again manually,
doing a restore verify of course, says it's good. At night
when the maintenance job runs, in the morning it says the
file is not a valid backup set. I run chkdsk and get
errors. At night we have a 3rd party backup program that
kicks off and around the same time I have this error in my
system logs: Event ID 12503 - The Distributed Link
Tracking log was corrupt on volume Z: and has been re-
created. This log is used to automatically repair file
links, such as Shell Shortcuts and OLE links, when for
some reason those links become broken.
I have deleted and re-created the job, and this past week.
I've been running the job manually in the evening, the job
will run once successfully at night, but if I allow it to
backup through the jobs the following night. I get that
it's not a valid backup set again. Confusing huh?
Has anyone experienced such a thing? And if so, please
share how you fixed it? If not, any suggestions are
greatly appreciated, because I'm fresh out of ideas.
Thanks,
JosieJosie,
Hello!
Looking at your problem, it appears to me that you could be looking at some
disk corruption. The best place to start would be the Event logs and see
if:-
1. You see any corruption or hardware errors
2. Did the backups actually complete successfully?
3. Is the database corrupt? (Run checkdb)
With SQL Server backups, we usually have commands such as RESTORE
VERIFYONLY and RESTORE HEADERONLY to verify the state of a backup device. A
backup can be deemed as successful only after it's been fully restored, and
a checkdb is run on it.
I'd suggest you look at the event logs, and maybe get your hardware vendors
engaged as well. Have you tried backing up the db to another drive?
Vikram Jayaram
Microsoft, SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
Subscribe to MSDN & use http://msdn.microsoft.com/newsgroups.