Irregular activity regarding drives and their paths across the master server and media servers in an ACSLS environment with SSO

[rjrumfelt]

We replaced two drives yesterday, and ran tpconfig on both in order to update the serial numbers to keep everything consistent.  We also varied the drives offline in ACSLS in order for it to pick up on the drive changes.  We have a number unix and windows media servers sharing these drives, and backups to the unix media servers are running just fine, however the Windows media server backups attempting to use these drives fail (the error code is 98, but I don't think the error code is very helpful in this situation). 

Some other odd behavior we noticed was that yesterday, after running tpconfig, the serial numbers were updated correctly under "Device Monitor," however today when we checked it out, the drives had the serial #'s of the old drives.  Could there be config files on the media servers that are somehow overwriting attributes on the master server?

So my main question is, are there any steps that need to be taken on our Windows media servers in order to completely update the paths for these drives?

[J_H_Is_gone]

I never worked with ACSLS but I do have SSO and unix servers

Windows seems to pick up the change to the new drive ok but unix (well at least my aix) servers require me to rmdev the rmt from the unix server then on aix I run cfgmgr again to get it back (do only 1 at a time so they don't change rmt#'s) .  now my aix servers show the correct "new" serial number that it presents to NetBackup.


So my thought is if you look on the UNIX server the rmt may still be showing the old serial number and you need to get them to seeing the new serial number.

[rjrumfelt]

Thank you for the suggestion, I will definately try it out.

One thing that we just did, and I'm hoping this might lead to something positive as well, is that rather than rerunning tpconfig, we used tpautoconf -replace_drive.  This seemed to take care of any discrepancies (the two drives in question were listed) being reported by tpautoconf -report_disc

[Anonymous]

For replacing drives, once the hardware device files have been sorted out at the UNIX OS level, this is what I do.

On the master run the tpautoconf -report_disc and then use the details to run tpautoconf -replace_drive

Then using the GUI I run the Device Configuration Wizard to update all the device details on the other SSO Media Servers.

This last step is recommended, rather than command lines these days.

[rjrumfelt]

However, we noticed something else rather odd.  when running sgscan, 2 of our drives are not picked up on the master server.  We have not noticed before, because other drives were being used.  The only backups that are occuring on the master are the catalog backups.  

I am wondering if I need to do an sg rebuild in order for sgscan to pick up these two drives.  These are not the two drives we had replaced.

[rjrumfelt]

We logged in today and for some reason the serial #'s reverted back to the originals, not the #'s of the newly replaced drives.

We're scratching our heads at this point.  We've have been doing exactly what Stewart said he does, and it is fine when we check everything right then and there.  But when we go home for the evening, and come back, the serial #'s have reverted.

I'm wondering if there is some config file deep in the bowels of EMM that we're failing to update.

[J_H_Is_gone]

GUI
go to devices/drives
find one that you have an issue with
In my example I have 4 servers sharing drives
so when I open up one if the drives all 4 severs show
choose the server that is wrong and delete it.
now say ok to let netbackup update it.

Now open it again and  add - it should look for the drive on the missing server that has the same serial number as shown in the gui.  If it does not show it with the same serial number then you still have an issue on the media server reporting the correct drives.
if it does show it add it back in.

Now see if it reverts back tomorrow.


(I never use the autoconfig because I just have never been able to get it to work right for me --- but that just may be me ;o})