Vault fail with error 306
Hi
We usually have Vault run on mondays, but for some reason i had to run this on wednesday this week. It only copies the full backups which runs on Fridays, so i changed the amount of days it needs to go back in order to get theese full backups. I added 3 additional days to it. I had around 63 empty tapes in scratch before i started the Vault. Today morning i saw the Vault job, and it had failed with error code 306. I did some research and figured that it failed because there were no media left in scratch. Usually vault does not use more then 20-25 Tapes pr vault session, so wonder why it used all 63 of them still wanting more.
Only reason i come up with is that i might have screwed it up when editing amount of days it goes back to get hold of all the full backups. It was set to 3 days and 6 hours, so i changed it to 6 days and 6 hours (basically added 3 days). So it might have gotten some full backups even from thursday. We usually run full backups only on fridays, but we might have some full backups running even on thursday.
When trying to eject the tapes of this particular Vault session, it only shows 3 Tapes, meaning that it never managed to end the jobs on rest of the 60 tapes. I ran the following command on some of the media ID which i had in scratch prior to start of Vault session: nbemmcmd -listmedia -mediaid <media_ID> and here is the output: (notice that i have removed some of the sesnsitive data from this log)
NBEMMCMD, Version: 7.6.1.2
====================================================================
Media GUID: d82d47e0-360a-11e5-8000-e7571c8337b0
Media ID: 100805
Partner: -
Media Type: HCART
Volume Group: 002_00000_ACS
Application: Netbackup
Media Flags: 1
Description: ---
Barcode: 100805
Partner Barcode: --------
Last Write Host: < removed >
Created: 07/29/2015 13:59
Time Assigned: 07/29/2015 15:36
First Mount: 07/29/2015 15:44
Last Mount: 07/29/2015 15:44
Volume Expiration: -
Data Expiration: -
Last Written: -
Last Read: -
Robot Type: ACS
Robot Control Host: NONE
Robot Number: 0
AcsAcs: 0
AcsLsm: 2
Cleanings Remaining: -
Number of Mounts: 1
Maximum Mounts Allowed: 0
Media Status: FROZEN
Kilobytes: 0
Images: 0
Valid Images: 0
Retention Period: 8
Number of Restores: 0
Optical Header Size Bytes: 1024
Optical Sector Size Bytes: 0
Optical Partition Size Bytes: 0
Last Header Offset: 0
Adamm Guid: 00000000-0000-0000-0000-000000000000
Rsm Guid: 00000000-0000-0000-0000-000000000000
Origin Host: NONE
Master Host: <removed>
Server Group: NO_SHARING_GROUP
Upgrade Conflicts Flag:
Pool Number: 6
Volume Pool: Offsite
Previous Pool Name: scratch
Vault Flags: -
Vault Container: -
Vault Name: -
Vault Slot: -
Session ID: -
Date Vaulted: -
Return Date: -
Media on Hold: 0
====================================================================
Apart from thoose 3 tapes which it had written successfully to, rest of 60 media ID returns with same result, basically having no valid image on them and in a Frozen state. Should i simply use the bpexpdate command to start reusing them?
And i will appreciate if someone could explain why this session used so many tapes, could it be the days i ammended in the Vault policy?
One more thing is if the medias are FROZEN , first try to determine why those medias are frozen, if these are new medias or old one where atleast one successful backup has happened.. If you think all is OK you can unfreeze the medias using bpmedia -unfreeze -m <mediaID> command and retry a tape operation to see if the media is freezing again.
I am surprized that you are seeing this problem only now...
This has always been a problem with pre-labelled tapes received from STK/SUN/Oracle - their tapes have been pre-initialized with ANSI headers.
You need to add
ALLOW_MEDIA_OVERWRITE = ANSI
to bp.conf on all media servers attached to ACSLS (or use Host Properties -> Media Servers -> Media)You then need to use bpmedia command (NOT bpexpdate) to unfreeze the frozen media.
