Vault doesnt eject tapes from volume pools if second copy

[nick80]

Hi

I have a backup policy which is configured to do inline copy.

Copy 1 writes to Volume Pool A (Primary to remain onsite)

Copy 2 writes to Volume Pool B.(Secondary to be offsited)

In Vault, Volume Pool B has been added to the "Choose Backups" and "Eject" tabs, however on running the Vault job it WILL NOT Eject any of the tapes in Volume pool B.

I KNOW THERE IS NOTHING WRONG WITH THE VAULT CONFIGURATION ITSELF AS I AM ABLE TO GET THE TAPES TO EJECT FROM VOLUME POOL B IF I DONT DO MULTIPLE COPIES.

The thing is I have read the documentation and confirmed that the way we have designed this appears to be exactly how Symantec recommends it to be implemented.

Hopefully someone has come across this before and can help.

Thanks

Nick

[mph999]

What does the detail.log say.

From memory it is in ...

/usr/openv/netbackup/vault/sessions/<sid>/logs/detail.log (or similar ...)

I suspect in fact that this will be down to the vault profile.  The log will confirm if I am correct or not.

In the 'Choose backups' screen for the vault setup, on the right you have the ability to select the 'source volume group' and 'volume pool'.  If this is set to anything other than 'All' there is a possibility that this is the cause.

From the documentation

"Selecting Volume pools restricts the search for images to those in either all volume pools or just the volume pools that you choose to include in your search. An image is selected for duplication or vaulting if any fragment of its primary copy is found in a media that is from any of the selected volume pools."

If you have for example, set the volume pool to 'vol pool B' and this  is not the primary copy, it won't eject.

If I am correct, this will probably work

So simply make volume pool B the first copy, then it will be primary, as with multiple copies, copy 1 is always the primary.

Vol pool B ejects with multiple copy, because then, volume pool B will be the primary copy.

Of course, if you don't have the profile set as I described, the cause is something else, but based on what I know at the moment, there is a possibility you have it set like this, in which case my description fits exactly.

Martin

[nick80]

Hi Martin,

Thanks very much for the comment. I did think about just changing the order but then again the reason for leaving the primary copy onsite is to enable quick restores. Having to promote the onsite copy whenever a restore is needed is far from ideal.

Your extract does seem to give an explanation as to why I am experiecing  this issues but here are the extracts from documentation that led me to believe this is how it should be done : (I think I might need to get Symantec to confirm this 100%)

Ensure that primary copies on removable media remain on site in your robot. If the primary copy is off site, a user-initiated restore operation waits indefinitely for a mount of the offsite media.
If you create multiple original backups during a NetBackup policy job, do not assign the primary copy to an offsite volume pool unless you intend to send it off site. If you assign the primary copy to an offsite volume pool, it is ejected and is not available for restore or duplication operations.

■ Use a NetBackup policy to create multiple original backups, assigning the copy to be vaulted to an offsite volume pool in any of the robots. For each robot, configure one vault and one profile that ejects the backups that were assigned to the offsite volume pool in that robot. Only backups on media in the offsite volume pools specified on the Eject tab and that meet the rest of the criteria specified in the profile are ejected.

Thanks

Nick

[nick80]

Oooppps, just noticed your a Symantec employee, sorry. But we may need to get an oficial statement, as its going to cause a huge floor in our whole design around how we do multiple copies and offsite one of these copies.

If you have any other suggestions it would be nice to hear. We opted to go for inline copy instead of duplications to enable us to offsite quicker and free up the daytime window.

[mph999]

No problem ...

If you have source volume selected, this must contain fragments of the primary copy.  There is no way around this.

I have a couple of ideas but as I think the issue is caused by using the 'source volume pool' then, if you set this back to any, I think it will work.  As you have the copy going to a separate volume pool, then I don't think you need the source voume pool  to be set anyway.

I would test this, but only have a VTL, which is really tricky to eject tapes from ...

Martin

[thesanman]

I do something similar and it works.  I duplicate "in-line" and even via SLP.

Check the job log, there will be an initial reference to (something like):

02/15/2013 05:15:15 - begin Duplicating Images
02/15/2013 05:15:15 - vault duplication validation of 136 images failed: Already duplicated

The reference above is to my duplicates that were written overnight and thus are ready, on tapes in my offsite pool and ready to be ejected.  Do you see something like this?

The problem might stem for the fact that the vault itself must select the images for duplication and then reject them because the offiste has already been made.