Video Screencast Help

Replicating .bkf files

Created: 29 Jan 2013 • Updated: 05 Feb 2013 | 11 comments
This issue has been solved. See solution.

Currently I'm replicating BE12.5 BKFs with homebrew scripts and it just catches up anything partially or not copied

Comments 11 CommentsJump to latest comment

pkh's picture

You should not copy .bkf files.  See this document

Reasons why copying backup to disk data files is NOT recommended.

You should always duplicate your backup set.

DavidSte's picture

How do you recommend duplicating backup sets between standalone BE12.5 media servers in different sites seaprated by WAN links?

pkh's picture

AFAIK, you cannot do this with BE 12.5.  With BE 2010/2012, you can do so using optimised duplication with dedup folders on both ends.  You would also need to have CASO.

VJware's picture

Does the second media server run any backup jobs ?

DavidSte's picture

Yes, the second media server just backs up the folder containing the BKF files to tape.  No remote agent based selections though.

teiva-boy's picture

Folks replicate BKF files all day long using devices like datadomain, Exagrid, SAN replication etc...

All it means is that the restore process involves a few extra steps to catalog and inventory the BKF's.

As long as you can maintain some sort of consistency, ive seen it in use and restorable going many years back, almost a decade.

There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) "We backup data to restore, we don't backup data just to back it up."

pkh's picture

I guess you have not read the document referenced in my first comment.

teiva-boy's picture

The article points out the pitfalls of doing a manual copy, but you need to understand since you don't have a good long history with the product, that these work arounds were spawned because the product inherently lacked the required features for years until BE2010.  Even then, it forces customers to buy more hardware and licenses.  And the reliability of those new features were questionable at best and a number of support engineers couldn't even help getting it setup and working

Even in that article, the very last two bullet points, point out exactly what I was talking about and have done for many years.  Going as far back as 1998 or so as a customer, then a deployment engineer, a reference customer, then a Symantec Employee (who handled the training and fixed a lot of issues in the field for 12.5 and 2010).

Compared to other backup products, some aspects of BE are just so dead simple.  A catalog import or DR catalog restore is cake!  When compared to the likes of NBU, EMC's Networker, bakbone and more.  What I can achieve with dedupe and a solid OST appliance too makes it pretty damn fast as well, beating NBU for a fraction of the cost.

There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) "We backup data to restore, we don't backup data just to back it up."

pkh's picture

Do not assume what you do not know.  I started using BE in 1994 when it was sold by Arcada.  

You always do not think much about official advice from Symantec.  It is fine for you because you know the pitfalls of doing do, but for others, you are leading them down the garden path.  As I said before, it is easy to give advice when you don't have to face the music.

If you are still a Symantec employee, perhaps you should ask Symantec management to stop wasting company resources writing these documents since they are drivel and are going to be ignored by "experts" like you.


Since you posted your diatribe after Colin Weaver's post below, I take it that you disagree with him as well as the document referenced by me.  As such, you should challenge the document's validity and get it pulled.  Also, why didn't you challenge Colin Weaver's statements? Are you afraid of challenging someone from Symantec Technical Support?


Colin Weaver's picture

Also going back a number of years we have seen some high profile customers get the consistency of what they are replicating wrong and then have big problems when it comes to a restore which is why we don't recommend it.

As such you should take time to understand the document that pkh referenced.

 For info Backup Exec 2012 slightly reduces the chances of issues, as this version

a)  only allows overwrite jobs to disk storage, which means you cannot end up with a huge media family that then gets inconsistent with the catalog and inventory info. In other words no append means max number of media in media family is the total media needed to back the individual backup set in question. and can no longer be infinite.

b) creates a new media familty for every backup set (so C: would be one set of disk media and D: would be another etc) (although virtual server GRT does slightly affect this)

However these changes only reduce some of the potential problems, they do not reduce or avoid all of them.

DavidSte's picture

As it happens, this point is moot for me as I'll be moving to BE 2012 Optimized Dedupe, once it kindly starts working properly (the thread was spawned from another relating to issues with Optimized Dedupe), but it's a good discussion to have anyway :)