Duplicate to tape problem

[Afonso_Martins]

Hello,

I have a backup to disk, then after this is finish there is a job to duplicate to tape.

Yesterday, the duplicate to disk finish ok and also the duplicate to tape.

The duplicate to tape dosen't have any error messages, but if i go to the restore option,  i realized that 3 servers were not duplicated to tape.

I can see that the servers were backup on the backup to disk, but why did the duplicate to tape didn't backup all the data that was backup on the backup to disk job?

Thank you,

[Afonso_Martins]

Hi,

Yesterday it was my montlhy backup and i had the same problem again.

I have daily, weekly and montly backups, and this problem is only happening on the weekly and montly backups.

The problem is, the backup to disk is ending properly and it makes around 700MB of data, but the duplicate job will only backup 200MB.

If i go to check the backup, i can see that the duplicate backup is not backing up all the media that it should.

I have tryed to recreate both weekly and montly duplicate templates but i had again this problem yesterday.

If someone could help me i will appreciate

Thank you,

Afonso

[Michael_McKenne]

Try to create a single isolated job.

Disk to Disk

Disk to Tape

Is BE stopping on Disk to Tape before completing?   Is it compressing the Disk to Tape file from 700 to 200?  Can you restore it to another location and check the sizes and what is missing?

[Martin_P]

Having the same issue.  Backup to disk runs fine, but when I duplicate that to tape it does not duplicate all of the data.  Review of the logs shows it not going through all of the B2D's that were created (it stops after awhile). 

Last backup job had 250gb of 700gb duplicated before finishing (no errors).

Any resolution to this?

[Howard_Brown]

Hmmm... I am seeing a similar issue. I initially attributed the difference in size to compression, however, looking at it, there are some things that do not appear to be going to tape.

For example, backing up our Sharepoint Server Farm, the Index DB is backed up through the "front-end" server.

The rest of the databases are backed up through the database server (both servers are backed up using the Sharepoint Portal Server Agent Option, GRT).

The Index DB does not appear in the job log of the duplicate operation. Everything else does.

--H Brown

[jiambor]

I am having the same issue.  My full backup with do about 1.4 TB to disk and then the duplicate will only do 350 GB to tape, but indicates it is successfull.  When I check the duplicate job, it only duplicated about 5 of my 20 servers.  I have tried recreating the prolicy without any luck.  I know it had worked fine when I originally created it.  Has there been any update on this issue?

Thanks

Message Edited by jiambor on 07-09-200706:29 AM

[btushaus]

I am having the exact same problem when a duplicate backup job runs that is linked to another backup job.  If I let the automatically scheduled duplicate job run, only about 350 GB of data is duplicated to tape wherease the linked backup job contacted about 1.8 TB.  If I manually create and run a duplicate job and in the selection list select the media set that original backup job used, the duplicate job processes about 1.5 TB of data...but again the original backup job processed 1.8 TB.

I am not using a policy based job...instead, this is just a backup job created and then a duplicate job linked.  The article located at http://seer.entsupport.symantec.com/docs/289787.htm indicates that this is known problem for policy based jobs.  This article also seems to indicate that running a manual duplicate job is a viable workaround...however as described above when I did this, I still had a discrepancy in my byte count.

Has anyone been able to come to any resolution with this issue?

[knightstorm]

This is frightening!!!  I have yet to see this on our setup, but we are also doing this and relying on the tapes for our archival and off-site backups.  I have just added the "workaround" to our daily operations.

[bboerst]

Is there any update on this?  I'm having the same issue as the people above -  My actual backup jobs have totally different byte counts than the duplicate job.  For example, my file server backup job ran this weekend and produced a byte count of 1,118,439,241,096 and the duplicate job was only 665,987,274,665.  I followed the suggestion on Symantec's KB entry (http://support.veritas.com/docs/289787) by running the job manually but this doesn't appear to be working for me because the byte count still isn't correct - even though I manually ran a duplicate job.
I have all hotfixes installed (1-14).
I would think that this would be a pretty critical patch to work on since I'm sure that there are people out there that don't even notice that this is happening (and are sending tapes offsite that don't contain all of their data even though they THINK that they do).
Can we at least get an update to know that it's being looked at?  Thanks!

[Kevin_Hammond]

We are also experiencing the exact same problems and we have also tried to perform the workaround and manually duplicate the backup jobs.

Nothing has worked so far.  Right now we are considering our options and considering moving back to 10d.

We have not had a reliable tape archive backup since we upgraded and as everyday passes we lose more historical backup archives.

[bboerst]

We were also kicking around the idea of rollilng back to 10d but as part of our 'upgrade' to 11d, we purchased a new 64-bit server to use as our media server so 10d is out of the question for us.
I agree - we also have not had a reliable tape archive backup since we upgraded back in May.

I actually opened up a case with Symantec on Monday regarding this issue but haven't really gotten anywhere.  The tech on the phone advised me to disable compression on the backup-to-disk and the duplicate job and this appears to have taken care of the difference in the byte count but now I'm running without compression and there's no way that this will work in the long run since we're backing up close to 1.7TB on the weekends.

I wish they'd release a hotfix for this one...

[Ben_L_]

Hey guys,

I did some checking this morning on that issue. While it is a known issue with policy based duplicate jobs, it is something that is getting worked on at this point.  I can't say when or if a hot fix is scheduled for release at this point though.

Regards,

[Kevin_Hammond]

Thank you for the update.

We are also trying to disable compression, but now we are running out of disk space everywhere so we are in the process of adding disk space for our B2D space.  We might run out of tape space too without compression...  Oh soo much fun.

[Fly_Guy]

I just came across this thread today... don't bother trying to go back to 10d as it does the same **bleep** thing.  I've been searching for answers on the forums.  The KB article indicates that it is a known issue for 11d, but doesn't mention anything about 10d.

Not that anyone at Symantec is going to care, but let me state right now that this is also a

** known issue for 10d **

Joel

[bboerst]

Yeah, I rolled us back to 10d last week in hopes of fixing this... didn't work for me either.  I'm still having the duplicate to tape issues.  I just can't believe that this isn't higher on their to-do list.  I've got to imagine that there are lots of people out there that don't even realize that this is going on - they see a successful duplicate job and don't even notice that the byte counts don't match up (or they attribute the difference to compression - which it's not).

I've been happier with 10d at least...

[Kevin_Hammond]

We have had success disabling compression on the B2D jobs.  The scheduled duplicates have been working since we disabled compression on the B2D portion of the jobs.  It seems that we can still enable compression on a duplicate to tape even with compression disabled on the B2D job.

The funny thing is that if we duplicate from a B2D job to another disk and we enable compression that way, then we don't get any compression on the duplicate job.  So it seems compression on a duplicate job only works if you have a hardware compression enabled tape device.

This solution strained our disk resources and we needed to buy some more disks, but at least everything is scheduled adn working now.

Kevin

[knightstorm]

Have you tried using Windows data compression on the B2D media directory?  If the Symantec compression is causing the problem, this might work and save disk.  I've been think of trying this, but we have sufficient disk for now without compression.

[gfunk]

We thought about it as well, but we were concerned with the additional overhead and the fragmentation impact.  So we opted to buy more hard drives.  Big SATA drives are not that expensive these days and you can add a lot of capacity very quickly.  We have a mirrored off-site backup server so we don't need RAID sets for our B2D drives.

We just add each individiual SATA drive as a B2D device and pool them altogether in Backup Exec.  That has a nice side benefit of being able to stream multiple backup jobs from multiple servers to each individual SATA drive at the same time.

[PSI_Folsom]

Well, same problem with us here.  I just found this thread after posting one on the issue.  I CAN'T believe that Symantec has know about this issue for this long, and still has not come out with a hotfix!

FWIW.  We were successfully using 11d for a couple of months, with our policy based B2D2T jobs.  We only started to experience the problem when we added a 64 bit Windows server to the selection list for the job.

So it looks like the best work-around is to create the B2D and B2T jobs seperately, without using a policy; and to turn off compression on the B2D job.  Is that what most people are having luck with?

[Daniel_Lauritze]

Hi all.

 Im having a problem, 4th. month in a row (since upgrade more or less - and it not like my boss is happy about it)

 But i only use B2D with exchange... this is mostly for restore purpos... this part works very well.... but.. a depended job - D2T, copying the exchange backup from the same disk to tape, allmost completes...  but.. acually never does..

 Its not a huge exchange store - around 80Gb, and as i said, B2D works just fine... but  the D2T "stalls" at around 68GB..... after this weekend i came back to what should have been a complete backup, only to finde that D2T has been stalling for 62 hours!!!  making anything else queued ... hurra.....

 Backup Exec 11D is fully updated and so is the Windows 2003 server... this cant be right...  pretty displeased, coz im taking the heat fom "upstairs" - and think i did my job well...  argh