Video Screencast Help

decomissioning a media server that is assigned images (both disk and tape)

Created: 14 Nov 2012 • Updated: 02 Feb 2013 | 7 comments
This issue has been solved. See solution.

Master: Windows 2k8 running

Media server #1: 5220 Appliance running 2.5.1

Media server #2: Windows 2k3 running

Shared tape robot connected to both Media #1 and #2

We're in the process of switching back to a 5220 from tape after fixing some rather serious errors on the 5220. 

I'm trying to decomission Media Server #2 but, since it has been a full fledged media server, it has both tapes and images assigned to it.  The images actually reside on the 5220.

I did try the nbdecommision command and it cleaned some things up but didn't complete things (both disk and tapes) are still assigned to this media server and it won't delete from the devices list.

I can get a list of these images (both tape and disk) with this command (in a DOS window):

bpimagelist -server oldservername -d 10/01/2012 | grep IMAGE | awk "{print $6}"

And that seems to match the "images on media" report if I filter it for that media server.

But when I then feed the resulting list (or even just one of the image numbers) into this command (or a FOR Loop version for the entire list):

bpimage -oldserver oldservername -newserver 5220name -id idnumber

it comes back with "no entity was found"

The 5220 is still hooked to the tape drive so it should be able to accept responsibility for tapes.  And it's where the disk images are living so....

How do I change the media server assciated with an image (either tape or disk)?

Comments 7 CommentsJump to latest comment

revarooo's picture

Why don't you assign everything over to the new server? (basically just omit the -id <idnumber> ?

Or do you want to assign specific images to specific media servers?

D.Flood's picture

Because I misread the documentation on that command and thought that the image ID was required...

Ok, after a bulk reassign now both lists are clear but the decomission script still can't delete the server and neither can I manually since it still says that fragments still exist.

Our backup window has opened for the night so I guess I'll have to wait until morning to see if overnight processes clean things up more or if I need to cycle all the master services to finally clean that media server off the list.  That's one thing I've learned about doing anything with NetBackup related to master or media servers...if it doesn't work now, wait overnight and sometimes it'll start working in the morning.

mph999's picture

"....  decomission script still can't delete the server and neither can I manually since it still says that fragments still exist."

Do you have disk storage units on this media server ?


Regards,  Martin
Setting Logs in NetBackup:
D.Flood's picture

Yes, it had a basic disk storage unit that I was sending catalog backups to. 

The decomission script disabled the catalog backup because of this.  I've since fixed it to go elseware and I expired the catalog backups that were listed as being on that unit.  But of course image cleanup can't actually delete them since that storage unit is no longer listed...

Oh boy did I mess this one up or what?

revarooo's picture

ah! Never mind we all make mistakes, it's an easy enough one to make. 

Do you know what the images are that are stuck? Have you tried to expire them manually?

D.Flood's picture

I expired them through the GUI (did a search in Catalog/Verify and then right click / expire).

bpimagelist -d 10/01/2012 | grep IMAGE | grep -i servername

seems to only show the actual backups of that server.  The date is a couple of days before we quick-built the server to restore access to our robot so I don't need to go back any further than that.

Since I need to turn that box off tomarrow to do a hardware/OS refresh I guess I better open a ticket so I can work interactively with a Tech...

D.Flood's picture

Turns out that I have an issue somewhat similar to TECH189892

So a lot of low level digging will be needed to decommission this server...

I guess the new box will have a new name since this name will still be in use as of tomorrow.