Media Mysteriously Moved To Different Media Set And Then Overwritten

[Howie_Goodson]

I have 4 Media Sets. Full (for a weekend full backup), Incremental (for daily backups of altered data), Exchange (for email backups), and Engineering (for a full backup of certain databases each night). I set up the backup jobs (4) to look for media in specific Media Sets. Everything usually works perfectly. However, every once in a while I will see media in the wrong Media Set. At first I thought it was a mistake on my part by dragging them to the wrong places when I created the tapes but now that this has happened 4 times I'm sure it's not an error on my part. Here is the latest example:
The Full backup ran Sunday morning at 12:00AM. It is set to write to media in the "Full" Media Set. It completed normally and wrote to a tape named "Full 1". After it finished it appears that the tape "Full 1" was moved out of the "Full" Media Set and into the "Engineering" Media Set and then the next morning when the Engineering backup ran it overwrote the tape "Full 1". I have the logs to prove that this is what happened. Nobody has access to the server but me and I didn't move it. I'm baffled. Any idea why it would do this? Why is BE moving my media around in the first place? How do I force media to remain in a certain Media Set and NEVER EVER move unless I move it myself?

[Renuka_-]

1. When a job is launched it searches for overwritable or appendable media (depending on what you selectedin the job settings) in the targeted media set.
2. If it does not find it there it searches it in the either the recyclable media or sratch media.(again depending on your setting)This setting is done in : Tools>Options>Media management.
3. If the search reaches a recyclable media (directly or after searching in scratch whichever way as per ypur settings) This media is currently allocated to a media set but is recyclabe.
4. Recyclable media is that whose Overwrite Protection Period is expired.
5. Recyclable media will be assigned to some other media set at that moment. But since it is recyclable it is picked up for the job. The job completes on this media.
6. THE MEDIA THEN GETS ASSIGNED TO THE MEDIA SET THAT IS SELECTED IN THE JOB PROPERTIES.
Thus causing the media to jump from the previous media set who's OPP is zero to the new media set in the job properties.

To understand better the process of media management, please refer to the following technotes:

1. The chapter on 'Managing media' on page 191 in the administrator's guide :
Title : VERITAS Backup Exec (tm) 9.1 for Windows Servers Administrator's Guide (English)
http://support.veritas.com/docs/266190

2. Title : The basics of Advanced Device and Media Management for VERITAS Backup Exec (tm) for Windows Servers
http://support.veritas.com/docs/192265

3. Title : An explanation of the "Overwrite Protection Period" and the "Append Period"
http://support.veritas.com/docs/237374


NOTE : If we do not receive your intimation within two business days, this post would be marked assumed answered and would be moved to the ‘answered threads’ pool.

[Howie_Goodson]

The problem is things change and using the Overwrite protection thing is far to restrictive and hard to administer. I need a way to assign a media that can be overwritten at any time to a Media Set and then have it stay in that Media Set indefinitely. If the backup job can't find media in the correct Media Set then it should fail. It should NOT go looking for media in Media Sets that I did not specify as valid for that job. how do I accomplish this?

[ray_littlefie1]

The whole objective of media sets is to set levels of protection of the data on tape. You wish the capability to overwrite data at any time- which defeats this basic objective.
It sounds like you want a physical division of tapes- you want tape "ABC" to be for Engineering no matter what (as an example). You can accomplish this with library partitioning (I'm just assuming you have a tape library). Library partitioning divides library slots into sections that you can point individual jobs to. Weekly backups only go to slots 5 & 6, and daily jobs only go to slots 3 &4 for example. It's up to you to ensure that the correct tapes go into the correct slots.

Media sets (in my opinion) are a lot less administrative overhead and become absolutely necessary when you have requirements for data retention. If you have 50+ jobs and 200+ tapes you can't live without them - but you need to let go of assigning data to specific tapes.

[Howie_Goodson]

This is how it SHOULD work:
I create a backup job called "Full" and assign the Media Set "Full Backups" to it. When that job runs it should look for any overwritable media (based on the OPP or physical accessibility) in its assigned Media Set. If it can't find any media that meets the criteria then the backup job should fail. It should NEVER EVER go looking in other Media Sets for media no matter that the OPP settings are. To me (and everyone else in our IT department that has tried to help me with this) it defeats the purpose of segmenting the media into Media Sets in the first place. I do not want BE to second guess my decisions and screw up my backups (royally as is the case with our Year End backup that got hosed because BE just decided it would go hunting for new tapes willy-nilly in other Media Sets when the Engineering backup filled it's tape). I want it to do exactly what I told it to do and if that isn't possible it should do nothing at all. I don't need the software to think for me because so far it has failed miserably to do so with any degree of intelligence.

I'll try the partitioning thing you suggested.

[Deepali_Badave]

Hello,

Try partitioning the library.

Please refer the following technote:

http://support.veritas.com/docs/262055

Also verify if you are getting any alerts in this case.

NOTE : If we do not receive your reply within two business days, this post would be marked assumed answered and would be moved to answered questions pool.

[Howie_Goodson]

Partitioning the autoloader worked. However, it is a redundant step that I consider to be a workaround to an inherent flaw with the way Backup Exec handles Media Sets. We have used other enterprise level backup software in the past and they offered the equivalent of Media Sets but never wandered around looking for media that wasn't in the Media Set that was allocated to a particular job. That defeats the purpose of the having Media Sets in the first place. When I discovered that this is what Backup Exec does I was completely blown away. It is not logical and serves no purpose that I can see other than to complicated and confuse the backup process (not to mention causing the loss of valuable data). I am very disappointed that this is the case.

[Steven_Vass]

I totaly agree with this user, setting up loader partitions is a extra step that should not be required to have separate media sets. I too lost a full backup overwritten by a different media set. None of my tape backups were full, and there were extra tapes available from their respective media sets!

[Thomas_Born]

We've got the same problem since two years. Veritas or now Symantec does not seem willing to change this behaviour of BackupExec.

[Derek_Tom]

I FULLY agree with Howie's feedback.

As I see it, the way BE handles Media Sets is BROKEN and ILLOGICAL.

Worse, it has caused numerous users to LOSE DATA because of the flaw.

As Howie put it, BE "should NEVER EVER go looking in other Media Sets for media no matter that the OPP settings are" and "if it can't find any media that meets the criteria then the backup job should fail".

Veritas/Symantec: So how about it... can this be fixed soon?

Please have the decency to respond to your customers' legitimate concerns here.

BTW, this issue is apparently the same issue I have reported here:

BE v10.0 uses wrong Media Set with Dell PV-122T
http://forums.veritas.com/discussions/thread.jspa?threadID=60599&tstart=45

Thanks,
Derek

[steven_johnson]

I had to partition my library as well - I don't think they are ever going to fix this issue. Took me about 2 months to figure that out.

[ray_littlefie1]

It's not broken.
I respect that Backup Exec does not adhere to some individuals concepts of how media management should behave. However, that's what the free download and evaluation is for.

ArcServe offers a free download.
Dantz/EMC Retrospect offers a free download: http://www.emcinsignia.com/try/
Commvault sales people seem friendly enough
etc, etc,.

While you're evaluating other solutions, partitioning the library with Backup Exec may meet your short-term requirements.

There are many people happy with Backup Exec. They backup, restore, and they don't loose data. I am one of those individuals.

[Ken_Putnam]

I've got to agree with Ray -

If it were truely "broken", out of the thousands (tens of thousands?) of people who bought v9 and v10 (as well as v8 and v7,which all use the same media management philosophy), would only a handful complain?


No, a handful didn't bother to read and understand the manual before deploying a production product, and as a result, because it didn't behave the way that they think it should, rather than the way it has for 4 versions, at least, got burned.


Next time RTFM! and don't tell me you don't have the time to read it, it's your JOB to read it - make time.

[Howie_Goodson]

Hello? Have you ever done a search for this topic? There are far more than a "handful" of people having a problem with this.
The reasoning behind drawing the conclusion that this is a design flaw in BE is quite simple actually. The way BE handles OPP's and Media Sets renders Media Sets useless (and as you say, has done so FOR 4 VERSIONS!). Why use them if your tapes are going to go wandering around on their own visiting different Sets whenever they feel like it? Have you ever tried to find a specific tape out of HUNDREDS when you can't even be sure which Set it decided to live that day?
And seriously, you don't think software should behave the way it's users expect it to? As a programmer myself that has to think about the programs I write from a users perspective, I cannot fathom this attitude... And I promise that you would never catch me coding in a feature that defeats another feature and renders it useless. That my friends is called, lack of direction, faulty logic, and just plain bad programming.
RTFM you say? Cute. I read the manual. I tested the software. I never in a million years would have expected BE to have this flaw or behave in this manner. Also, I'd like to point out that putting a known flaw in the manual and touting it as a "feature" does not make the problem go away.

[Ken_Putnam]

I hate to keep harping on this, but you say that you DID read the manual.. If that is so, regardless of how you think the product SHOULD operate, you did know how it WOULD operate.

if you had data that should not have been overwritten, why were the media set properties such that the tape volume was in overwritable status when the "rogue" job looked for an overwritable tape? If the samd tape had been mounted by mistake when an overwrite job that DID specify that media set ran, the data would still have been ovewritten.

And no one has yet mentioned the Global Option to use overwritable media in the target media set before other overwritable media or vice versa. Was that set properly?

I've used BackupExec since v6.0 on NT 3.51 and I've never had any of the problems that are touted as FLAWS show up on my systems. Does that mean that I'm just lucky? or that I set out to learn how the software operates, and used it as it was designed to be used?

[Howie_Goodson]

*sigh*
Again, I read the manual. I ran the tests. Believe me or not, I don't really give a... Everything worked fine. However, I never expected BE to maliciously jump Media Sets when tapes were filled to capacity and overwrite tapes that were in other Sets and nothing I read indicated that this would happen. This behavior is totally illogical. Are you saying I should attempt to reproduce scenarios in testing that are so stupid I can't even imagine them? That is unreasonable to put it nicely.

Granted, my OPP settings were quite "loose" due to the fact that I was using the Sets themselves to administer the media and assign the Sets to the jobs. This works great until a tape fills up. When that happens you are skeeeroood! I found this out the hard way and have since remedied the problem using partitions as a workaround to this design flaw. All the documentation in the world will never convince me that this is not a product of very poorly skilled design team.

My problem here is not that my data was lost. Spilled milk and what all. My arguement stems from the fact that if Media Sets worked the way any sensible human being would expect them to you wouldn't need to rely on OPP settings to protect your data any where near as much if at all! Anyone that has used Yosemite's TapeWare (and just about any other backup software suite on the market) knows exactly what I'm talking about. If everyone else can do it right why can't Symantec? I hold all software developers accountable for their products and poor design is poor design. In this case it's also dangerous.

One thing I do not tolerate is someone telling me something cannot be improved simply because "that's the way it is". Unacceptable.

[STeve_O]

Backup exec is working by design there is nothing wrong with it. I manage hundreds of tape with no issue. If you read the manual and manage you backup then there is no issue. If you dont like it buy another product or use NTBACKUP

[Howie_Goodson]

> Backup exec is working by design there is nothing wrong with it.

That is my point. It works exactly as designed which is the problem.

> I manage hundreds of tape with no issue.

As do I now that I know how to work around the problems inherent in the software's design.

> If you read the manual and manage you backup then there is no issue.

Except for the fact that BE will jump Media Sets and overwrite media in Sets that aren't even assigned to a particular job. How can you guys think this is not a bad design in need of improvement?

> If you dont like it buy another product or use NTBACKUP

Avoidance of accountability for a bad design is not the answer.

Trust me, if I had a choice in the matter I would be using Yosemite's TapeWare. However, such is not the case and I have no control over the software choices made by our corporate office. I'm sure they based the decision to use BE on price with no consideration for any other factor. All I can do is bring these problems to the attention of the vendor which is what I'm trying to do here. It's not even a problem for me anymore as I've stated above. The partitioning workaround is great for getting around the flaw. I would simply like to see Symantec give it some thought and realize how illogical Media Set handling is in their current product so that they can fix it in an update or later product. In short, I'm trying to help them by pointing out a bad idea. I know how frustrating this problem can be from first hand experience and I would like to save some of my fellow IT colleagues from the same trouble.