Video Screencast Help
Symantec Appoints Michael A. Brown CEO. Learn more.

Massive Bug in BE 2014

Created: 08 Jul 2014 • Updated: 10 Jul 2014 | 7 comments
PrisonerZero's picture
1 Agree
0 Disagree
+1 1 Vote
Login to vote

Hello

I have found a fundumental flaw in BE 2014. This is after a BE 2012 - 2014 upgrade.

Our backup strategy is as follows.

  • Backup to Disk
    • Full + Daily Incrementals / Differentials
    • 1 week retention
  • Duplicate to Tape
    • Immedietly duplicate to Tape after completion of Disk based backup
    • Duplicate Full & Incrementals / Differentials
    • 4 week retention.

 

So the problem is that BE 2014 sees the backups duplicated to tape as dependants of the Disk based set. So the disk based chain expires as it should, but the Data Grooming never deletes it, as it sees the copies on Tape as dependants. If I expire the tape copies, then the Disk ones gets deleted OK.

 

So unfortunetly my Disk is starting to get filled with expired backup chains, that will not be deleted until the Tape copy expires. And there is no way of deleteting them manually.

Symantec Support has directed me to install Hotfix 217591 & 218257 but the issue is not fixed.

 

Comments 7 CommentsJump to latest comment

Frank_'s picture

I have exactly the same issue (problem) and this will be problematic after 2 weeks because the disk is full then.

The last 14 months with BE2012 were horrible. This is the last change for Symantec. I will try this until the end of summer. Then I will quit BE2014 and buy another product after 15 years Backup Exec.

 

 

0
Login to vote
Artegic's picture

I'm planning to upgrade from 2012 to 2014 with a quite similar backup strategy so I'll watch how this idea fares before embarking on that adventure.

0
Login to vote
FJR1300's picture

Trying to think this through, and it might be more complex than I'm making it but wouldn't you want to have your diffs/incrementals on tape expire before you would want the full on disk to be deleted anyway for an optimal restore process? We expire our dup'd fulls in 5 weeks, but our dup'd diffs in 14 days.  I think it's only the diffs/incrementals that are dependent.  It won't matter that you've got unexpired fulls out there on tape.

I could change the 14 days down to 7 days on the tape diffs if we needed more space, but we are doing ok at the current levels.  I don't see any behaviour change for us on this situation from 2012, but I'll keep an eye on it.

0
Login to vote
Artegic's picture

The point is that disk space is more limited than tape space, so there must be a way to delete backups from disk but keep them on tape. Simple as that. Of course a restore will take longer if it must be made from tape because the disk copy has been deleted.

The alternative would be to delete the backup from tape, too, when it has to be deleted from disk because of space limitations. Restores from that backup would then be impossible instead of slow. I wouldn't consider that optimal.

0
Login to vote
PrisonerZero's picture

Ive had an update from Symantec, the engineering team is working on this issue. So far, ive been manually expiring HDD backups sets just as the HDD runs out of space. This unfortunetly expires the tape duplicates too, but until Symantec fix this, its the only way,.

0
Login to vote
moon1234's picture

This is also a major problem for me as well.  We run weekly fulls and daily differential to disk and then dupe to a tape library.  The disk backup is simply to speed up backups from multiple servers so they complete in time.  Once that is done we dupe to a Tape Library onsite and retain for 6 months.  We also dupe to tape and transport offsite for storage for 7 years (medical device manufacturing laws). 

This idea of marrying the dupes on tape to the disk backup is STUPID.  I had used a registry entry to allow expiring of on disk backups that still had dependents on tape in 2012.  This worked fine as we set the media retention to what we needed on the library and offsite backups. 

It is almost like the coders at Symantec do not work in a corporate environment and just make assumptions and changes to the code willy nilly and we are left to try and work around their bad decisions.  It would be nice if they actually engaged people in differnet industries or exposed options in the GUI so we could at least tailor the software to work the way we need it to.

0
Login to vote
Colin Weaver's picture

I believe you have this issue

http://www.symantec.com/docs/TECH223215

 

Current intention (although it is still being qualified so subject to change)  is to fix this in the General Release of SP1.

For anyone using the SP1 Pre-release / beta that is reading this, it is not fixed in that version (and yes the general release will upgrade the version you have)

0
Login to vote