Hi Nicholas,

If the branch office machines are just clients then you can simply go from 7.1.x to 7.5.x

If you are upgrading server, the safest path would be to upgrade to 7.2.2, then 7.3 or 7.4 and finally 7.5. You will need two upgrade enablers (7.3 and 7.5). 7.1 to 7.5 should work. Just make sure you keep the bootstrap info available and make a zip / tar of the /nsr/mm, /nsr/res and /nsr/index in case you have problems, and run nsrck -m/nsrim-X/nsrck -L6 before you get started to make sure the databases are in good condition.

Kevin

Hi Kevin

Thanks for the advice.

Yes these are 7 x NW 7.1 server instances

I have done a few Server upgrades on Solaris platforms but not many on Windows. I think I'll do a bit of testing to see what I can get away with - bring the media db, resources and indexes to a scratch test server then install various NW server versions & see what works.
I seem to remember when I went from 6.1 to 7.2 there were some format changes to the resource files - so will be suprised if i can go straight up to 7.5 without staging thru 7.2

I was hoping to avoid this job & that the links to the branches would be upgraded so i could turn them into storage nodes of our enterprise server!

Not sure if the indexes back to the server would saturate the link - would like to test but dont think that a server can be a storage node of another server?

Hi Nicholas,
At Powerlink, you can find the "Technical Guidance for Upgrades to EMC NetWorker 7.5", P/N 300-008-997. There are some considerations about the upgrade.
Regards

Hi Nicholas,

You can see the answer at esg69260 solution:
"Cause: A NetWorker server cannot be setup to act as a storage node for another NetWorker server in the same data zone. A server can only "serve" one data zone.
Fix: The server with the storage node device must be demoted to a storage node or the NetWorker Backup and recover service can be stopped and the user can then successfully label the volume from the remote server."
Regards

Hi Nicholas,

Your NW servers cannot be a storage node of another NW server, you need to make them storage nodes, and besides the 7.1 storage node cannot work with a 7.5 server. It is a good idea to make the old NW servers into storage nodes. The only way to bring the indexes and volumes into the production server would be to scan them in, otherwise you'll have to keep a scratch server around to get your data back prior to the cut over....

Hope this helps

Kevin

As they have said you cannot use your remote servers as storage nodes for the test. However you could test throughputs just by copying data with FTP and seeing how long that takes.

Yes thanks David

Thats what I have been doing today. I have the size & utilisation of the current pipes to the branches. I'm hopeful that I can go down this route. Would probably need to force the indexes to write to tape at the branch rather than pull them back here to the server.

We have an unlimited retention period for backed up data (dont ask) so indexes get quite large!

Only issue I can see is that if we get the branch staff to do the tape labelling I cant see how to limit them to a subset of devices via the GUI e.g. only the one in their branch. Otherwise somebody here at base will have to do it which is a pain & suffers from miscommunication.

Remember your indexes are stored on your backup server and not the client so the index data crossing the WAN is not going to change except with the amount of files you add. Your indexes will grow but generally that does not impact things much but the media database will also grow and when that starts to get very large you may start to see performance suffering. If your /nsr/mm directory starts to go above 1GB then you should start to think about splitting the server, though if this is a distant proposition then perhaps Networker will be able to handle larger media db at that point!

good points. Thanks