03-16-2011 12:17 PM
I'm having a lot of trouble getting a good copy of my De-duplication Storage folder for DR purposes. As advised, I'm making a backup of "Shadow Copy Components\User Data\Backup Exec De-duplication Storage" and running this to a B2D file.
However, 90% of the time, this fails with
Final error: 0xe000fedf - A failure occurred reading an object.
--------------
Backup- Shadow?Copy?ComponentsWARNING: "Shadow?Copy?Components\User?Data\Backup Exec De-duplication Storage\Storage" is a corrupt file. This file cannot verify.
Verify- Shadow?Copy?Components - VSS Writer File SystemWARNING: "Storage" is a corrupt file. This file cannot verify.
This error happens at random points in the backup - the byte count is different every time. A chkdsk of the destination drive is clean.
I have no trouble with the backups of the servers themselves - this error only happens when I try to do the DR backup job, so I know the Dedup store is good.
Restarting the server and/or BE services makes no difference.
I actually have had to make a template job that will re-run the copy if the first one fails so that I can be sure to get a good DR copy. It still fails often, even after three tries.
I experimented with making a duplicate data job but that doesn't work for us because it makes an uncompressed, re-hydrated B2D file. We're using de-duplication because of space and bandwidth issues so this kind of defeats the purpose.
I've attached one of the job logs if anyone is interested.
The media server is a Dell PE860, 8GB RAM, Xeon X3220, Windows 2003 Std R2 x64; Dell PERC 6/E, Dell MD1000 storage array, RAID-5, 6.1TB with 1.45TB free. Backup Exec 2010 R2 SP1, fresh install for both OS and BE.
Solved! Go to Solution.
03-23-2011 08:30 AM
Solution found.
Follow the advice in this Technote:
http://www.symantec.com/business/support/index?page=content&id=TECH42646&key=15047&actp=LIST
And these Microsoft KB articles:
http://support.microsoft.com/default.aspx?scid=kb;en-us;312362
http://support.microsoft.com/default.aspx?scid=kb;en-us;304101
The sweet spot for me was setting the PoolUsageMaximum value to 50.
I have run several backups now with no failures since.
03-16-2011 01:15 PM
More info from the Application Log:
Event Type: Error
Event Source: Backup Exec
Event Category: None
Event ID: 57476
Date: 3/16/2011
Time: 11:46:25 AM
User: N/A
Computer: SONORA
Description:
The operating system returned an unusual error while backing up the following file:
D:\Backups\Deduplication Storage\data\1558.bin
It is possible that this file is incomplete and therefore should not be restored.
For more information, click the following link:
http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml
Data:
0000: 02 00 00 00 04 00 00 40 .......@
0008: 00 00 00 00 00 00 00 00 ........
0010: 00 00 01 00 00 00 00 00 ........
0018: 00 00 00 10 00 00 00 00 ........
0020: 00 00 e9 0e 00 00 00 00 ..é.....
I reviewed the log and all the failures are accompanied with an event like this, referencing a different file each time.
03-16-2011 02:51 PM
Did you try getting rid of the verify part of the job? I know that doesn't play well with dedupe. You can do a verify job later on. If you have a 2nd dedupe server and a dedupe folder on that 2nd server instead of a disk based backup you can do a duplicate job to it. After the first job the rest of them fly and take little space across the WAN.
03-16-2011 02:56 PM
The backups are failing during the backup part of the job, not the verify.
This is only affecting the backup of the dedup storage folder. Regular backup and verify jobs for individual servers run fine.
03-16-2011 03:53 PM
I notice a marked improvement when I uncheck the verify that is included with the job. Don't know why.
03-23-2011 08:30 AM
Solution found.
Follow the advice in this Technote:
http://www.symantec.com/business/support/index?page=content&id=TECH42646&key=15047&actp=LIST
And these Microsoft KB articles:
http://support.microsoft.com/default.aspx?scid=kb;en-us;312362
http://support.microsoft.com/default.aspx?scid=kb;en-us;304101
The sweet spot for me was setting the PoolUsageMaximum value to 50.
I have run several backups now with no failures since.