04-18-2017 04:45 PM
Hello Geeks,
I have an env running with 7.7.X and i would be replacing a drive in it.
I am refering to this below article to replace the drive as do not want to run the device wizard post replacement.
https://www.veritas.com/support/en_US/article.TECH34296
As per the article i should give the old scsi ID to the replced drive , may i know how i can do that and is it a mandatory step ?
Thanks
Shelton Q.
Solved! Go to Solution.
04-18-2017 11:21 PM
I'm not sure why the TN mentions the scsi ID, it doesn't mater.
The key is this command
tpautoconf with the -replace_drive <drive name> -path <drive path>
... which is well you tell NBU - relace the drive with <this drivename> (which will be in 'missing state' with the drive that is found at <drive path to new drive>, eg. /dev/nst4 (if that was the OS path to the new drive).
Even if the new drive had the same path as the old, you would need to run the command as NBU tracks drives via the serial number, and would therefore know the drive was missing.
04-28-2017 10:47 AM
I done with the replacement , it worked with tpautoconf method itself.
I have my drives sso enabled,here is the procedure i followed.
1. After repalcement , checked the drive in library for its status (It was showing online)
2. Down the drive from NBU.
3. ran tpautoconf -report_disc (robot control host)
4. It listed me Missing and the New drives.
5. ran tpconf -replace_drive <old Drive Name> -path <new drive path>
6. It shows the message as "Found Matching device found".
7.Now again , ran tpautoconf -report_disc to check is there any missing device (None reported now)
8. Made the drive Up from netbackup end.
9. restarted the device daemon on all media servers sharing the drive .
Command : volmgr/bin/stop ltid & ltid
10. NBU started utilizing the drive.
04-18-2017 08:48 PM
Hi,
The assignment of SCSI id's is not under NetBackup control. You can check with your hardware / OS vendor.
04-18-2017 11:21 PM
I'm not sure why the TN mentions the scsi ID, it doesn't mater.
The key is this command
tpautoconf with the -replace_drive <drive name> -path <drive path>
... which is well you tell NBU - relace the drive with <this drivename> (which will be in 'missing state' with the drive that is found at <drive path to new drive>, eg. /dev/nst4 (if that was the OS path to the new drive).
Even if the new drive had the same path as the old, you would need to run the command as NBU tracks drives via the serial number, and would therefore know the drive was missing.
04-18-2017 11:29 PM
I personally do not like the method in that TN.
I have over the years seen too many problem reported in the forums with that method.
After confirming that the OS can see the drive (using scan command), I would delete the old drive, restart ltid, then add the new drive - either using the wizard or else manually )GUI or tpconfig). Then restart ltid again.
04-19-2017 06:35 AM
04-19-2017 07:57 AM
No, you don't need to delete and recreate STUs.
Just confirm that the drive is added with same robot number and drive density.
This will ensure that STU properties remain valid with no need to reconfigure.
Be sure that you delete the old drive first, restart ltid on all media servers (all via GUI).
When using the wizard, select all media servers that share this drive.
Be sure to double-check new drive is seen on all media servers (using scan) before re-adding it.
I do not recommend manual add in SSO environment.
It means you will have to do it on each media server and remember to specify same name and other properties exactly.
04-19-2017 11:09 AM
The drive which you are going to replace will be the same type of drive which is right now in the Tape Library?? If so, you will have to do nothing apart from following steps given by Library Vendor.
Typically, you will have to make the drive offline (power down), remove cables if attached and replace it with new Tape Drive. NetBackup should automatically detect the new Tape Drive with OS device number remaining the same.
I have this hands on experience in Windows environment and If I remember correctly I have done the same in Unix environment. All, please add your comments if you have other thought.
04-19-2017 02:40 PM
I would do this in the following seqence , please correct me if any changes required.
1. Delete the old drive from Devices --> Drives ---> Select and delete the old drive.
2. Run scan command to check newly added drive is visiable on both media servers.
3. If it is visible , will run the Device Config Wizard through GUI and select both servers for SSO and check the density.
Here is my doubt after the 3rd step , this wizard will actually take me to STU configuration . How should i proceed at this point ?
04-19-2017 09:24 PM
04-20-2017 03:54 PM
Thank You , will include the steps and will try quiting the STU config and update you .
Many thanks for all the reponses
@Marianne wrote:
Remember to restart ltid/Device Management Service on media servers after step 1.
At the end of step 3 you will be prompted to config STUs. It is not automatic. You can quit the wizard here.
04-24-2017 04:14 AM
I have always love to reconfigure the whole devices to prevent conflict. Once yo confirm you can see drive from OS, you can run the below
/usr/openv/volmgr/bin/tpconfig -d - to see drive index
/usr/openv/volmgr/bin/tpconfig -multiple_delete –drive
/usr/openv/volmgr/bin/sg.build all -mt x -ml x
/usr/openv/volmgr/bin/driver/sg.install
rm -f /kernel/drv/sg.conf
/usr/openv/volmgr/bin/tpautoconf -a
/usr/openv/volmgr/bin/tpconfig -d
04-28-2017 10:47 AM
I done with the replacement , it worked with tpautoconf method itself.
I have my drives sso enabled,here is the procedure i followed.
1. After repalcement , checked the drive in library for its status (It was showing online)
2. Down the drive from NBU.
3. ran tpautoconf -report_disc (robot control host)
4. It listed me Missing and the New drives.
5. ran tpconf -replace_drive <old Drive Name> -path <new drive path>
6. It shows the message as "Found Matching device found".
7.Now again , ran tpautoconf -report_disc to check is there any missing device (None reported now)
8. Made the drive Up from netbackup end.
9. restarted the device daemon on all media servers sharing the drive .
Command : volmgr/bin/stop ltid & ltid
10. NBU started utilizing the drive.