09-14-2010 01:57 PM
Hi,
We are having an issue were are backups are failing with error code 96, no available media.
We contacted support and saw under the scratch pool -> change that the "Scratch Pool" was not checked so we checked the box and the backups grabbed the tapes.
Then, this morning we checked and the box is unchecked again. I'm the only one that manages backups for this site so I don't know how it's getting unchecked.
I've checked the box and restarted Netbackup services and it still goes to unchecked.
We are running Netbackup 6.5.5.
Thanks.
Solved! Go to Solution.
09-14-2010 02:09 PM
There are no 'known issues' that describes this behaviour in 6.5.5 :
http://seer.entsupport.symantec.com/docs/336998.htm
We also have quite a number of customers on 6.5.5 that have not reported this behaviour.
Please check that vm.conf on the master is updated:
(install_path\Volmgr\vm.conf)
SCRATCH_POOL = pool_name
09-14-2010 02:09 PM
There are no 'known issues' that describes this behaviour in 6.5.5 :
http://seer.entsupport.symantec.com/docs/336998.htm
We also have quite a number of customers on 6.5.5 that have not reported this behaviour.
Please check that vm.conf on the master is updated:
(install_path\Volmgr\vm.conf)
SCRATCH_POOL = pool_name
09-14-2010 02:58 PM
Well, I just saw this scenario the other week. Customer had a lot of status 96 after upgrading to 7.0.1. The scratch pool was not marked as scratch pool anymore (been since Jan 2008).
I didn't reflect further, but just assumed operator error and corrected the problem, but reading your note, I'm eager to investigate further in order to see if we can re-produce.
Have they upgraded from 6.5.4 to 6.5.5 recently? Could be an upgrade issue... Look at 7.0.1, it replaces the pd.conf file (PDDE/PDDO configs) so that any site-specific settings are lost... So it might be possible that an error occurs for scratch as well.
Historically it has been an issue if 2+ people use the admin console or Java console and made updates. This could lead to some inconsistencies. But if there are only one or a few admins, this issue rarely occurs.
/A
09-14-2010 03:33 PM
The vm.conf looks like it's probably the issue. I just checked it and the only entry in there was MM_SERVER_NAME = "our master server". Nothing else was in it.
I assume it needs to be populated with more information. I just checked one of our other Nebackup master servers and it has DEVICE_HOST and MEDIA_ID_BARCODE_CHARS defined.
09-14-2010 06:16 PM
To the extent that we had a number of major weekend backup failures, and I wrote a script to check and correct for it using PERL on windows.
1) Ensure that the path to netbackup and volume manager binaries are defined
2) I use blat.exe, co-located with the script to send a warning email
3) Schedule the script to run every 30minutes to an hour during the backup window
#!perl -w #use strict; # This script uses NetBackup command line tools to check the following: # 1) That the SCRATCH pool is defined, sending an email if this changes. # Define some variables my $ADMIN = 'XXXXXXXXX@YYYYY.COM'; my $SUBJECT = "SCRATCH Pool Issue"; my $EMM_HOST = "MASTER-SERVER-NAME"; my $SCRATCH_POOL = "SCRATCH"; my $FOUND_SCRATCH = 0; # Is the SCRATCH pool still active? open VMPOOL, "vmpool -h $EMM_HOST -list_scratch|" or die "Cannot read from VMPOOL: $!"; while (<VMPOOL>) { # Clean up raw data (line feeds, leading and trailing spaces) chomp ; s/^\s+// ; s/\s+$// ; # If line begins with the name of the pool, the scratch pool is configured $FOUND_SCRATCH = 1 if $_ =~ /^($SCRATCH_POOL)/ ; } close VMPOOL; # Did we find the scratch pool? $SUBJECT = "NetBackup: SCRATCH Pool Issue"; if ($FOUND_SCRATCH == 0) { # Attempt to set the scratch pool system "vmpool -h $EMM_HOST -set_scratch $SCRATCH_POOL"; # Email the admin team and let them know open(MAIL,"|blat.exe - -to \"$ADMIN\" -s \"$SUBJECT\""); print MAIL "An issue was deteced with the SCRATCH pool. I have attempted to fix it. Please check as soon as possible.\n\n\tPerl Script on Master Server."; close MAIL; }
09-14-2010 10:32 PM
Seems that you guys have identified a bug... Re-open call with Symantec and insist that they do more investigation.
There should not be any need for running scripts to constantly check.
09-14-2010 11:07 PM
refer this KB
09-15-2010 01:21 AM
You need to have entry in vm.conf which says scratch pool = scratch rest of the entries in vm.conf can define ur media server etc.
09-15-2010 01:33 AM
How is this TN related to scratch status being cleared?
09-15-2010 08:08 AM
OK, just got off the phone with support and I think we got it.
The scratch pool was defined in the gui, but just not working so we set it by the command line and it worked.
After running the vmpool -set_scratch scratch command seemed to have fix it.
We're going to monitor it for a few days and see.
09-15-2010 08:18 AM
BUG REPORT: The scratch pool attribute is toggled whenever the "OK" button is clicked in "Change" dialog for a volume pool.
http://seer.entsupport.symantec.com/docs/323377.htm
***EDIT***
Bit late to the party I know, but it may be something to watch out for as it may switch it off once more if you use the GUI again?
09-15-2010 08:40 AM
No, I was using the Java GUI, but that issue looks like we were seeing.
09-15-2010 08:50 AM
I thought that's what I asked?!
09-15-2010 11:39 AM
put the cup down & back away from the caffeine
09-15-2010 03:29 PM
Sorry, doing too many things at once.
Just normal Windows Console.