12-19-2013 07:16 AM
We have released NetBackup 7.6.0.1 and Appliance 2.6.0.1 on 18th December 2013(Yesterday), Let us start logging our experience in this thread... I have been testing NetBackup 7.6FA for some time, soon I'll be helping few customers with 2.6.0.1 and NetBackup 7.6.0.1 soon.
For more details please check following few good links.
sort.symantec.com
entsupport.symantec.com Enterprise NetBackup Server/NetBackup Appliances
Good Luck for your upgrades.
Khajan Gowda
01-09-2014 08:00 AM
01-09-2014 08:48 AM
It estimated 2 hours 20 minutes, before the upgrading I run the pddeobjectcount -e command, it estimated 3 hours 30 minutes with very slow disk.
This morning it finished , it took 17 hours.
01-23-2014 04:10 PM
I just read through all the posts. I'm not sure which saddens me more, the knowledge that what I thought (and was told) would be a 3-4 hour process could take 12-20 hours to complete or the loss of the Java Admin Console. Is the JAC available for 64b windows? I have a 64bit Win box on my desk that I use almost exclusively for NBU administration and if necessary, I could fire up a VM. I've tried several times to use the non-Java admin console, but it is horrible. I hope the JAC works on my 64bit box. I've started the process, so it's too late to go back now.
I was told to expect 3-4 hours for the process. I'm disappointed to hear that it's taking 2-4 times longer than that to complete.
One issue that I found during the upgrade process is the fact that the console screen 'blacks out' after a few minutes. This is a problem, since you can't see if an error occurs. I have been hitting the space bar occassionaly to wake up the screen, but there should be an option to disable this. On one of our appliances, when the screen went black the first time, I hit 'enter' to wake it up, which then cancelled the upgrade process when it got to the next yes/no prompt since no was the default.
01-24-2014 04:09 AM
Wes,
First there is and has been a 64-bit JAC. I have used it since 7.1.
Secondly on the overly long upgrades. I do not know but at our location the first upgrade took less time than the estimate. There is a situation where an EEB is not applied that does affect the conversion time. This had to do with TIR not being pruned and an overlarge catalog.
http://www.symantec.com/business/support/index?page=content&id=TECH209826
I had read in one of the forum posts that if this was not applied ahead of time and allowed to act then the catalog upgrade did do the pruning and that added time. The article has a link to the fix for a master server on an appliance.
01-24-2014 09:48 AM
We've gone ahead with the upgrade to 7.6 even though the 64Bit Java console "issue" hampers our ability to "easily" work with the system....
We have to remote to other (Windows 2008 or UNIX) systems to do the nuts and bolts administration.
We use the OpsCenter for monitoring operations and do the "easy" restores.
Where is the "vote" button on Symantec's site to "urge" them to provide a 32Bit Java Console.....?
Can it be that much different (difficult to implement)?????
01-24-2014 10:20 AM
WHat is the issue with the 64-bit console?
01-24-2014 10:44 AM
The there is no issue with the 64Bit console, except that all (our) administrator workstations are 32Bit....
The issue is that we no longer have Java Consoles on our workstations we must remote to another 64Bit system (servers in our case) just to get to a Java Console…
01-30-2014 02:11 AM
Hi All,
Ive just upgraded from 2.5.2 to 2.6.0.1 and get the following when trying to use appliance commands.
Network> Show Status
Cant call method "push_to_ipv6_addr_list" on and undefined value at /opt/NBuappliance/scripts/nbu_network_v6.pm line 737
Has anyone lease had this? I'm going to look at the code to see what its doing but is there a fix?
01-30-2014 02:41 AM
I have upgraded one 5220 and one 5230 and neither has this issue.
01-30-2014 06:42 AM
Has anyone else seen this?
01-30-2014 07:35 AM
Did 7504 to 7601 Solaris master server, it worked. Only curiosity was the BMR db which leaves you sat there for longer than the master server upgrade and seemingly nothing is happening.No feedback on cmdline, but it is running (and you can tell as the BMR db files can be seen to change). Our install is not large, so it went by the simple method.
Opscenter was the opposite. It didnt go at all well. Something unpleasant happened during that upgrade which although it claimed to have worked clearly didnt as I couldnt login to it, despite the monitor cmd showing it all running.
This demonstrates the value of the db backup beforehand.
Fix: copy aside the db backup data, uninstall opscentre completely,install 7601 from scratch, stop the db, copy the db files aside and replace with your db files taken earlier, the run the db upgrade. All working.
Jim
02-02-2014 10:44 PM
>> Only curiosity was the BMR db which leaves you sat there for longer than the master server upgrade
Please check this technote and follow the instructions. Seems you may need to purge your bmr db for unwanted entries causing upgrade delay.
http://www.symantec.com/business/support/index?page=content&id=TECH211811
Thanks.
Mandar
02-13-2014 08:05 AM
For our MSDP conversion, Symantec's estimate was (fast disk) 2h34m.
It took a total of 12h 33m 37s !!
02-13-2014 05:21 PM
Where is the "vote" button on Symantec's site to "urge" them to provide a 32Bit Java Console.....?
Can it be that much different (difficult to implement)?????
Sorry I didn't bring this up three weeks ago, but would you/someone consider creating an "Idea" and gathering some votes for it?
https://www-secure.symantec.com/connect/backup-and-recovery/ideas
I just checked to see if this was already there (so I could vote for it!) but came up empty.
02-21-2014 04:12 AM
Hello
I got the Unallocated space error to.
...
Checking for MSDP estimated time to upgrade...
02-21-2014 04:30 AM
The installtion does not concern itself with any space outside of the storage pools and that space that would be available to the storage pools. In the case you show the correct answer would be "Deduplication" . The installation then resizes the deduplication pool by that much to do the conversions. Later you can readd the space.
02-21-2014 08:46 AM
thanks that dit it!
but how do i readd the space?
03-28-2014 03:23 AM
One for Mandar I suspect...does the above process also address the issue Ive seen during BMR backup during catalog backup which now can take 30 minutes just to verfiy?
03/28/2014 07:03:48 - Info bpdbm (pid=29201) validating BMRDB backup in /usr/openv/db/staging
03/28/2014 07:29:51 - Info bpdbm (pid=29201) done validating BMRDB backup in /usr/openv/db/staging
Thats 26mins just validating it.The whole stage+validate job takes 31mins, so BMR is ~80% and historically it never used to take so long.The other 2 validates add up to no more than 2 minutes.
My bmr data db is 1.01G. As it happens I have one from 2012: 122M and we've decreased the number of BMR clients.
Thanks,Jim
03-28-2014 11:09 PM
Yes, I strongly believe post BMRDB purging using the method explained in the technote this catalog backup problem would go away.
Thanks.
Mandar
04-04-2014 07:53 AM
From my experience some of the numbers associated with bmrdb purging timescale should be taken with caution.
I have 1Gb BMRdb...the server is doing nothing...the purge is taking 1hr/5%.
So thats going to be 20hrs to purge the thing, contrast with the claimed time of (worst case) 45mins/Gb ie 45mins. Just an order of magnitude out...
Fortunately according to the technote at least, this wont affect ongoing BMR operations:I have no choice but to experience this now as the purge has no chance of finishing before my BMR backups start.
Jim