We are using a strategy that involves a policy which uses B2D during the night, and Duplicate to tape following the B2D.
I get this error every night, when the job runs to disk:
Verify- \\ES1\Microsoft Information Store\First Storage Group Difference encountered in file data.
The file Logs\Mailbox Store (ES1) is different.
This document is useless:
http://seer.support.veritas.com/docs/267554.htm
Since it does not seem to apply to 10d.
And I am assuming that because of the above (which may not be true), I get the following error when it runs to tape:
Duplicate Checksum on storage media failed to verify.
Data for Mailbox Store (ES1) is corrupt.
This is very frustrating, because with a policy based duplicate job and a B2D job that over-writes, the duplicate job must be deleted and recreated every day, or else BE tries to retry the duplicate indefinitely, which in turn results in ADAMM errors, because once overwritten, the data it failed to duplicate no longer exists. (I'd really like to see a fix for that!)
Our setup:
Windows Server 2003 Enterprise
Backup Exec 10d (FULLY patched to the latest)
The B2D folder(s) live on a 1TB striped RAID array (SATA II)
Remotes (including Exchange) are backed up over a GbE connection.
We are using Pre-Allocation, because heavy fragmentation of the drives containing the B2D folders was a major problem, and this fixed it nicely.
Hardware and/or software compression on the B2D folders is disabled. Hardware compression is enabled on the tape drive, which is a Dell 110t (IBM Ultrium LTO-3)
We back up a full backup on the weekends, and do daily differential backups, with the exception of the SQL Servers, and the Exchange Message store, which are always full backups. The brick-level backup of Exchange is a diff during the week, and a full on the weekend.
I have tried EVERYTHING that I can think of.
I have disabled the drive for Remote Storage, and installed the latest BE drivers, I have upgraded the firmware on the tape drive, patched BE to the gills - nothing seems to help, and I obviously can't stop backing up the message store.
Since the checksum is written at the same time the data stream is written, I just don't see how it could fail - it backs it up seemingly just fine.
TIA,
--H. Scott Brown
